Arquitetura Corporativa: Muito mais do que TI

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.


[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.

Frameworks de Arquitetura – Parte 2: TOGAF

No último artigo da série, discutimos o Zachman Framework, sua importância e influência como referência obrigatória a qualquer esforço de Arquitetura Corporativa.

Neste artigo, discutiremos em maiores detalhes o TOGAF 9.

TOGAF 9

Conforme discutimos na artigo anterior, uma das limitações do Zachman Framework é não prover orientações sobre como realizar o trabalho de arquitetura. Não sendo um padrão aberto, a metodologia para a construção e operação de uma Arquitetura Corporativa estão disponíveis apenas através de consultoria prestada por empresas ligadas diretamente a John Zachman.

Assim sendo, os praticantes de arquitetura criaram uma demanda para uma metodologia aberta de arquitetura que lhes ajudasse a iniciar e manter esta iniciativa. Com o tempo, entre os vários frameworks abertos disponíveis, o TOGAF (The Open Group Architecture Framework) se impôs como padrão de facto na área.

A característica distintiva do TOGAF (além do fato de ser aberto) é a disponibilização de uma metodologia amplamente customizável para orientar os esforços de arquitetura. O “coração” do TOGAF é o ADM (Architecture Development Method) que, como diz seu prórpio nome, estabelece uma metodologia para o desenvolvimento e manutenção de uma Arquitetura Corporativa.

O ADM é representado pelo seguinte diagrama:

TOGAF ADM
TOGAF ADM

Como podemos ver, trata-se de um processo iterativo. A Fase Preliminar é aquela na qual “colocamos em pé” o esforço de arquitetura, estabelecendo a equipe de arquitetura e definindo o método e metamodelo customizados a serem usados em nosso esforço de arquitetura. É aqui também que escolhemos ferramentas de repositório, definimos os processos de Governança da Arquitetura e obtemos o Patrocínio necessário para o esforço de arquitetura.

A partir daí, executamos iterativamente as demais fases do ADM:

Fase A – Visão da Arquitetura: Enquanto na fase Preliminar estabelecemos o processo de arquitetura, esta fase corresponde ao planejamento do projeto de arquitetura a ser executado nesta “rodada” do ADM. Trata-se de estabelecer uma visão de como deve ser nossa arquitetura futura para atender às metas estratégicas de negócio, que são a principal entrada para esta fase. O resultado desta fase é um Documento de Visão da Arquitetura, que documenta onde a organização quer chegar com sua arquitetura para viabilizar o cumprimento das metas estratégicas, e um Plano de Projeto para a execução desta “rodada” do ADM.

Fase B – Arquitetura de Negócio: Nesta fase, documentamos os estados atual e futuro (alvo desejado) dos Processos de Negócio da Organização. Equivale à elaboração da segunda linha do Zachman Framework, assim como a Fase A nos permitiu construir a primeira linha deste mesmo framework. O resultado da fase é o detalhamento das necessidades em termos de processos de negócio para atender às metas estratégicas, bem como um gap analysis que nos diz qual é a distância entre nossa situação atual (AS-IS) e a arquitetura em que queremos chegar (TO-BE).

Fase C – Arquiteturas de Sistemas de Informação: Nesta fase, identificamos os sistemas e dados necessários para atender à situação futura de processos de negócio desenhada na fase anterior, bem como nossa situação atual e a distância a ser percorrida (gap analysis).

Fase D – Arquitetura de Tecnologia: Da mesma forma, esta fase se ocupa de documentar as necessidades futuras em termos de infraestrutura tecnológica para atender às necessidades de sistemas e dados identificados na fase anterior. Mais uma vez, identificamos também nossa situação atual e a distância a ser percorrida.

Fases E e F – Oportunidades e Soluções e Planejamento da Migração: Nestas duas fases, consolidamos os gap analyses das fases B, C e D, e identificamos os projetos necessários para cobrir a distância a ser percorrida. O resultado é um portfolio de projetos para atingirmos nossa arquitetura desejada.

Fase G – Governança da Implementação: A rigor, o projeto de arquitetura desta iteração acabou na Fase F, tendo como produto o portfolio de projetos a serem executados para implementarmos a arquitetura desejada. Nesta fase, portanto, a principal atividade é a realização de revisões de conformidade, que são auditorias realizadas nos projetos do portfolio para garantir que estejam sendo executados de acordo com a arquitetura proposta.

Fase H – Gestão de Mudanças na Arquitetura: Propriamente falando, a Fase H não é uma “fase” no sentido de que não tem necessariamente um conjunto pré-determinado de tarefas nem um prazo para terminar. Trata-se de acompanhar no dia-a-dia a continuidade da relevância da arquitetura implantada na Fase G às necessidades estratégicas da organização. Mudanças no Ambiente de Negócios e na Estratégia exigirão mudanças na arquitetura, e o processo usado nesta fase deve ser capaz de separar pequenas de grandes mudanças. As grandes mudanças, tipicamente, exigirão a reentrada no ciclo do ADM, ou seja, o estabelecimento de um novo projeto, a ser iniciado novamente na Fase A.

Gestão de Requisitos: Mais uma vez, não se trata exatamente e uma “fase”. Esta atividade encontra-se – literalmente – no “centro” do ADM, significando que cada uma das demais fases do ADM ao mesmo tempo gera novos requisitos de arquitetura e utiliza como entrada os requisitos de arquitetura previamente identificados.

O TOGAF inclui orientações extensas sobre como realizar atividades de arquitetura. O ADM é o “centro” do framework, mas este ainda contém uma enorme quantidade de informação e orientações adicionais.

O TOGAF, hoje em sua versão 9, é atualmente o padrão de facto para Arquitetura Corporativa, sendo de longe o framework mais utilizado no mundo neste tipo de iniciativa. De fato, mesmo naquelas organizações onde se pratica apenas Arquitetura de TI (e não “Corporativa”, o que necessariamente inclui a Estratégia Corporativa e os Processos de Negócio), ele tem sido a opção escolhida.

Links

Outros artigos da série:

Parte I: Introdução

Parte II: 5 Razões para se tornar um Arquiteto Corporativo

Parte III: Por onde começar?

Parte IV: Frameworks de Arquitetura: Zachman

Parte V: Frameworks de Arquitetura: TOGAF

Outros artigos de Arquitetura Corporativa

Arquitetura Corporativa e Gestão de Portfolio de Projetos

Os 3 mal-estares do Planejamento Estratégico

Frameworks de Arquitetura – Parte 1: Zachman

É impossível falar de Arquitetura Corporativa sem discutir os diferentes frameworks associados. Os dois frameworks mais famosos são o Zachman e o TOGAF.

Mas o que é um framework de arquitetura?

Segundo a definição do próprio TOGAF, um framework é “uma estrutura para conteúdo e processo que pode ser usada como uma ferramenta para estruturar o pensamento e garantir consistência e completude.” Ou seja, um framework serve para “botar ordem na casa” (conteúdo) e “ensinar o caminho das pedras” (processo).

Por que os frameworks de arquitetura são necessários? Pela a simples razão de que a quantidade e complexidade da informação mantida em uma iniciativa de arquitetura são muito grandes, e que o processo para obter essa informação e construir e manter uma arquitetura são tudo menos simples. Os frameworks, portanto, fornecem essa estruturação para simplificar a vida dos arquitetos.

Vejamos os dois principais frameworks de arquitetura em maior detalhe. Neste artigo, detalharemos o Zachman Framework e, no próximo, o TOGAF.

Zachman Framework

John Zachman é considerado o “pai” da Arquitetura Corporativa. Foi ele quem delineou a disciplina, inventou o termo “Enterprise Architecture” e criou o primeiro framework, que leva seu nome.

Nos dois artigos em que introduz o tema (veja os links no final da página), Zachman explica o uso do conceito de “arquitetura” para o assunto que está introduzindo. A metáfora é mais que apropriada. Essencialmente, ele nos diz que, para construir uma casa, precisamos de diversas plantas de arquitetura, abordando diversos aspectos (estrutura, elétrica, hidráulica…) e destinadas a diversos públicos (o cliente que encomendou a casa, os diversos engenheiros envolvidos, o mestre-de-obras…). Além disso, precisamos manter essas plantas atualizadas para sermos capazes de fazer modificações e reformas no futuro sem risco (quem nunca furou um cano na parede?) Zachman nos diz que não é diferente com as organizações.

Em sua forma atual, o framework de Zachman consiste em uma matriz de 6 colunas por 6 linhas. As colunas correspondem às clássicas perguntas 5W1H (What/Who/Where/When/Why/How) aplicadas à organização. As colunas, portanto, referem-se aos diferentes aspectos sobre  a organização que precisam ser conhecidos:

  • What: sobre o que a organização precisa de informação? De que ela trata? Normalmente, essa coluna representa dados mantidos pela organização.
  • How: Como a organização funciona? Como ela processa seus dados? Esta coluna normalmente refere-se a processos e funções da organização.
  • Where: Onde as coisas acontecem? Aqui vão informações geográficas, de localização etc.
  • Who: Quem está na organização e quem faz o quê? Informações sobre pessoas e estruturas organizacionais estão aqui.
  • When: Quando as coisas acontecem? Questões relativas ao tempo aparecem aqui.
  • Why: Por quê as coisas acontecem? Aqui vão as informações relativas às motivações da organização, incluindo seus planos estratégicos de negócio.

As linhas da matriz referem-se aos diferentes pontos de vista e níveis de detalhe relativos à informação que descreve a organização:

  • A primeira linha contém o escopo e o contexto, e representa o ponto de vista do estrategista como teorizador sobre a organização. Normalmente, contém informação relevante para o planejamento estratégico de alto nível e, é claro, o próprio conteúdo da Estratégia da organização.
  • A segunda linha contém os conceitos de negócio, representando a visão da liderança executiva (vistos como proprietários dos processos de negócio e informações relacionadas). Contém tipicamente descrição detalhada da organização no nível de processos de negócio.
  • A terceira linha contém informações sobre os sistemas de informação (nível lógico), com a visão dos arquitetos de sistemas (designers).
  • A quarta linha contém informações sobre a infraestrutura tecnológica (nível físico) da organização, sendo o ponto de vista dos engenheiros enquanto construtores.
  • A quinta linha refere-se à descrição dos componentes que a organização utiliza para operar, sendo a visão dos técnicos-implementadores.
  • A sexta e última linha representa as operações propriamente ditas da organização, instanciadas pelos seus colaboradores participantes.

As células criadas pela interseção das linhas e colunas “armazenam” algum tipo de informação especifica que combina o aspecto e o ponto de vista correspondentes.

Tão ou mais importantes, talvez, que os conteúdos de cada célula, são as ligações existentes entre as várias linhas do modelo. Por exemplo, um repositório de arquitetura baseado no modelo de Zachman conterá informação, na linha 2, mostrando quais processos de negócio implementam ou estão relacionados com as metas estratégicas descritas na linha 1. A linha 3 mostrará quais sistemas de informação dão suporte a quais processos de negócio e a linha 4 mostrará quais itens de infraestrutura dão suporte a quais sistemas de informação, e assim por diante. É isso que permite a realização de análises de impacto, percorrendo o diagrama de cima para baixo – se mudarmos esta meta estratégica (linha 1), quais processos de negócio (linha 2), sistemas de informação (linha 3) etc. serão afetados? Fazendo o caminho inverso – de baixo para cima, temos a melhor ferramenta possível para analisar riscos organizacionais: caso este servidor ou link de comunicação pararem, quais sistemas irão parar, quais processos de negócio serão afetados e quais serão as metas estratégicas prejudicadas?

É importante observar que o framework de Zachman atente apenas parcialmente à definição do TOGAF, já que ele provê a estruturação da informação (conteúdo), mas não inclui per se um método (processo) para sua construção. Na verdade, trata-se apenas de um metamodelo. Essa é a principal razão pela qual arquitetos corporativos recorrem a outros frameworks para suprir essa necessidade. E o principal desses frameworks é justamente o TOGAF.

Outra ressalva ao modelo de Zachman é que ele tem um forte “sotaque” de TI: a partir da sua terceira linha, por exemplo, é bastante claro o foco em sistemas de informação, podendo dar a entender que esses são os únicos recursos organizacionais utilizados pelas organizações para dar suporte a seus processos de negócio. Essa é uma das críticas mais frequentes ao Zachman Framework, sendo que seus críticos mais ácidos o acusam de nem mesmo poder ser chamado de framework de arquitetura corporativa, mas apenas de arquitetura de TI.

TOGAF

A sigla TOGAF significa The Open Group Architecture Framework e dispensa maiores explicações, a não ser para explicar que se trata de um framework desenvolvido e mantido pelo The Open Group, entidade sem fins lucrativos mantida por seus membros, que são em sua maioria empresas de serviços de TI, tais como IBM, SAP e HP (a Gnosis é membro do Open Group).

Como dito acima, a popularidade do TOGAF se dá, entre outros motivos, pelo fato de ser um framework aberto (como tudo o que faz o Open Group – faz parte do nome, afinal) e prover um método para a construção e manutenção de uma arquitetura corporativa, algo que não é disponibilizado pelo Zachman framework.

No próximo artigo, detalharemos o TOGAF e veremos como ele se relaciona com o modelo de Zachman.

Clique aqui para ler o próximo artigo da série

Links

https://www.zachman.com/

Outros artigos da série:

Parte I: Introdução

Parte II: 5 Razões para se tornar um Arquiteto Corporativo

Parte III: Por onde começar?

Parte IV: Frameworks de Arquitetura: Zachman

Parte V: Frameworks de Arquitetura: TOGAF

Outros artigos de Arquitetura Corporativa

Arquitetura Corporativa e Gestão de Portfolio de Projetos

Os 3 mal-estares do Planejamento Estratégico

Por onde começar?

Supondo que você está convencido de que ser Arquiteto Corporativo é uma boa opção para sua carreira, por onde começar?

Para qualquer planejamento de carreira, uma vez que você tenha escolhido para onde quer ir, é necessário verificar quais são os conhecimentos, habilidades e atitudes esperadas para os papéis que você quer desempenhar. Tendo isso claro, é mais fácil saber por onde começar, especialmente no que diz respeito aos conhecimentos, já que estes são, entre os três, os mais fáceis de adquirir.

De que conhecimentos precisa quem quer ser Arquiteto Corporativo?

Um Arquiteto Corporativo é, antes de tudo, um generalista. Então, é fácil imaginar que é ampla a faixa de conhecimentos necessários. É conhecida a citação de Vitruvius:

“O arquiteto ideal deve ser uma pessoa erudita, um matemático, familiarizado com estudos históricos, um estudioso aplicado de filosofia, conhecedor de música, que não desconheça medicina, detentor de saber jurídico e familiarizado com astronomia e cálculos astronômicos.” – Vitruvius, circa 25 AC

Além de todas essas coisinhas básicas, um Arquiteto Corporativo deve ainda ter sólidos conhecimentos que lhe permitam conectar as várias disciplinas ou domínios que constituem a Arquitetura de uma Organização. Isto inclui Estratégia, Processos de Negócio, Sistemas de Informação e Tecnologia. Além disso, o trabalho do arquiteto é essencialmente um trabalho de Gestão de Projetos de Arquitetura, de modo que conhecimentos de Gerenciamento de Projetos são também fundamentais. Vejamos cada um desses domínios com mais detalhes.

Estratégia

O Arquiteto Corporativo tem como sua principal missão “arquitetar” a organização para que ela seja capaz de executar sua Estratégia. Então, é evidente que é por aí que temos que começar. É importante que o Arquiteto Corporativo tenha um sólido conhecimento dos principais modelos de Planejamento Estratégico e ferramentas associadas. Idealmente, o arquiteto fará parte do time de Planejamento Estratégico da organização. No mínimo, os seguintes itens precisam ser dominados:

  • Modelos de Estratégia Competitiva de Michael Porter. Porter é reconhecido como o pai da estratégia corporativa, e seus modelos são um dos fundamentos básicos de qualquer metodologia de Planejamento Estratégico utilizada nas empresas. O Modelo das 5 Forças, suas Estratégias Genéricas e seu conceito de Cadeia de Valor são o bê-a-bá de estratégia que todo arquiteto tem que conhecer.
  • A Teoria da Firma Baseada em Recursos e seu conceito básico de Competência Nuclear (Core Competence), que é um contraponto às ideias de Porter. O autor mais conhecido por trás dessa ideia é C. K. Prahalad.
  • A Estratégia do Oceano Azul (Blue Ocean Strategy), uma visão mais recente e muito influente que procura superar algumas questões das visões anteriores.
  • O Balanced Scorecard, provavelmente a mais usada técnica de Planejamento Estratégico na empresas hoje.
  • Ferramentas básicas usadas em Planejamento Estratégico, tais como a Análise de Pareto, o Diagrama de Ishikawa, a Análise SWOT, a Matriz BCG e tantas outras. Além disso, é claro que o Arquiteto Corporativo deve conhecer profundamente a metodologia de Planejamento Estratégico de sua empresa e, principalmente, a sua Estratégia em si.

Gestão de Processos de Negocio

A primeira forma pela qual a organização executa sua Estratégia é através de seus Processos de Negócio. Portanto, é evidente que essa é outra disciplina a ser dominada pelo Arquiteto Corporativo. No mínimo, os seguintes itens devem ser dominados:

  • Técnicas de Modelagem de Processos de Negócio. Em particular, e obrigatório o conhecimento da BPMN (Business Process Modelling Notation) e altamente recomendado o conhecimento da técnica IDEF, especialmente o IDEF0.
  • Metodologias de Melhoria de Processos. Existem inúmeras dessas metodologias, mas não se pode dizer que haja um padrão. De qualquer modo, todas se preocupar essencialmente em como transformar os processos de negócio atuais de modo a serem mais eficazes e/ou eficientes na execução da Estratégia.

Sistemas de Informação

A maior parte dos processos de negócio da organização é suportada por sistemas de informação que, portanto, são parte essencial da Arquitetura Corporativa. A modelagem de sistemas requerida de Arquiteto Corporativo é de alto nível, de modo que não é necessário que ele seja um profundo conhecedor. No mínimo, os seguintes itens devem ser dominados:

  • Técnicas de Modelagem de Dados. A arquitetura de dados e um componente fundamental da Arquitetura Corporativa. O Arquiteto Corporativo deve conhecer bem essas técnicas e o Modelo Entidade-Relacionamento.
  • UML (Unified Modelling Language). Boa parte das metodologias de sistemas das organizações hoje utiliza a UML como base para a modelagem e documentação de seus sistemas. Não há como o Arquiteto Corporativo deixar de conhecê-la bem.

Tecnologia

Os sistemas de informação da organização necessitam de uma infraestrutura tecnológica para serem executados, e isto também faz parte da Arquitetura Corporativa. Mais uma vez, não é necessário que o Arquiteto Corporativo seja capaz de montar em casa o seu próprio PC. Conhecimento dos principais componentes de computação e comunicação é suficiente.

Gestão de Projetos

O dia-a-dia do arquiteto consiste em tocar projetos de arquitetura e participar de outros projetos. Então, conhecer bem Gerenciamento de Projetos é também fundamental. Diríamos que existem aqui dois grandes conjuntos de conhecimentos necessários:

E as certificações?

Atualmente, a moda é correr atrás e acumular o maior número possível de certificações. Ok, certificações são importantes e tal, mas devemos lhes dar importância dentro de seu contexto. Teremos um dos artigos dessa série dedicado a este assunto.

E o que mais?

É claro que a lista acima e só pra começar. Além de outros conhecimentos, existem ainda as habilidades e atitudes, das quais ainda não falamos e que ficarão para um próximo artigo dessa série.

Você vê algum conhecimento adicional necessário ao Arquiteto Corporativo que eu tenha deixado de comentar? Quais são os conhecimentos mais importantes entre esses, em sua opinião?

Se você é um arquiteto experiente, não deixe também de contribuir aqui com os leitores, dando sua opinião!

Clique aqui para ler o próximo artigo da série

Artigos relacionados

Arquitetura Corporativa e Gestão de Portfolio de Projetos – Julho de 2009

Os 3 mal-estares do Planejamento Estratégico – Setembro de 2008

Gestão do Conhecimento e Cultura Organizacional: Uma Lição da II Guerra – Setembro de 2007

Analistas de Processos de Negócios: 5 Competências Fundamentais – Abril de 2007

PMBOK não basta: Entendendo como a Cultura e o Poder afetam os projetos – Março de 2007

Links

Outros artigos da série:

Parte I: Introdução

Parte II: 5 Razões para se tornar um Arquiteto Corporativo

Parte III: Por onde começar?

Parte IV: Frameworks de Arquitetura: Zachman

Parte V: Frameworks de Arquitetura: TOGAF

Outros artigos de Arquitetura Corporativa

Arquitetura Corporativa e Gestão de Portfolio de Projetos

Os 3 mal-estares do Planejamento Estratégico

 

http://blog.gnosisbr.com.br/sobre/serie-arquiteto-profissao-do-futuro/arquiteto-corporativo-profissional-do-futuro-introducao/

Cinco razões para se tornar um Arquiteto Corporativo

Vamos lá: por que você deveria se esforçar para se tornar um arquiteto?

Existem muitas razões, mas selecionei cinco delas para focar aqui.

  • Uma nova profissão (aspecto de novidade).

Pelo menos no Brasil, trata-se de uma nova profissão. Pouquíssimos profissionais tem “Arquiteto” impresso em seus cartões de visita. Isto, claro, tem dois aspectos interessantes. Um deles é o fato de que você se apresenta profissionalmente de forma diferenciada (o que vamos discutir no próximo item). O outro é mais intrínseco: você está na fronteira do conhecimento, tendo a oportunidade de participar da aventura da inovação.

Se você é daquelas pessoas que gosta de estar na frente, mesmo sabendo que não existem respostas prontas para as perguntas, a profissão de arquiteto pode ser uma opção das mais interessantes para você.

  • Saia do mar vermelho (PMP já era).

Como dissemos acima, o fato de esta ser uma profissão nova faz com que você se destaque da multidão (pelo menos nos próximos anos). Sejamos sinceros: PMP já era. Até o pipoqueiro da esquina é PMP. O PMI cometeu o erro de transformar a certificação em Gerenciamento de Projetos em uma vaca leiteira / caça-níqueis (e que níqueis!). Transformou sua certificação em uma indústria na qual a credibilidade caminha de forma assustadoramente rápida para o total descrédito. É impossível, hoje, distinguir um gerente de projetos competente e experiente de alguém que decorou “o livro da Rita” para passar na prova, já que o mais provável é ambos sejam PMP!

Mesmo que o diploma PMP ainda valha alguma coisa, é algo que uns 90% dos profissionais seniores (ou nem isso)  já têm ou terão nos próximos 18 meses. Não é diferencial nenhum, tornou-se “fator higiênico”, ou seja, algo que se espera “de saída”, como curso superior ou domínio da língua inglesa.

Fez muito sucesso um livro relativamente recente sobre Estratégia chamado “A Estratégia do Oceano Azul”. Essencialmente, o livro recomenda às empresas que parem de tentar disputar mercados abarrotados de concorrentes se esfaqueando (o “mar vermelho” de sangue) e procurem novos mercados onde não haja ninguém. No plano individual, podemos dizer que a profissão de arquiteto terá essas características por algum tempo: vai levar tempo para que o mercado esteja abarrotado de arquitetos!

Se você ainda não é PMP, corra para ser! Até porque experiência em Gerenciamento de Projetos é prerrequisito para ser um bom Arquiteto. Mas não caia na conversa de que isso vai lhe dar algum diferencial significativo em médio prazo!

  • Use todo o seu repertório (holismo, cultura pessoal etc.).

A profissão de arquiteto é por definição uma atividade holística. O arquiteto tem que ser um “poliglota”, falando “negociês” com o pessoal de negócio e “tecniquês” com o pessoal de tecnologia, sem esquecer o pessoal de RH, da Auditoria, do Jurídico…

É uma profissão perfeita para quem tem conhecimentos amplos. Sabemos que muitos profissionais de TI, embora usem conhecimentos tecnológicos no dia a dia, em algum momento se dedicaram – mesmo que por hobby – a outras atividades de conhecimento, tipicamente em ciências humanas, incluindo aí sociologia, história, ciência política, filosofia etc.

A boa notícia é que você precisará disso tudo para se destacar como arquiteto.

A má notícia é que você precisará disso tudo para se destacar como arquiteto.

O Arquiteto precisa ter uma visão holística, macro, geral, de alto nível sobre a organização e seu ambiente. Não é possível definir de antemão quais conhecimentos serão necessários, de modo que o repertório de cada arquiteto fará a diferença.

Portanto, se você é aquela figura tão comum na área, que estudou não sei que disciplina só pelo gosto de fazê-lo, essa é a sua chance de fazer esses seus conhecimentos trabalharem a favor de sua carreira e dos resultados de sua organização.

  • Entenda o negócio, sem deixar de entender de tecnologia (seja um generalista).

O arquiteto certamente não é um especialista. Nem em negócio e nem em tecnologia. O arquiteto concentra-se na floresta, e não nas árvores individuais. Por incrível que pareça, acredito que ser um generalista útil é bem mais difícil do que ser um especialista útil. Afinal, o especialista é capaz de mostrar imediatamente suas competências. O generalista, por outro lado, precisa de tempo. Portanto, prepare-se: não é fácil!

Espera-se do Arquiteto que ele tenha uma excelente compreensão do negócio que sua empresa opera, mesmo sem conhecer os ínfimos detalhes. Ao mesmo tempo, espera-se dele que tenha uma sólida (e atualizada!) compreensão da tecnologia. E, principalmente, espera-se dele que seja capaz de fazer a ponte, isto é, compreender como é que a tecnologia pode servir ao negócio de forma inovadora.

Há uma boa discussão sobre se ser generalista ou especialista é questão apenas de escolha ou de personalidade (ou ainda de outras características pessoais). Não vou entrar nessa discussão aqui. Mas, se você se sente atraído por muitos assuntos bem distintos, ao invés de um pequeno número de assuntos em um domínio restrito, é provável que você tenda a ser um generalista. Se for assim, a profissão de Arquiteto provavelmente é uma boa opção para você.

  • Abrace a estratégia (suba na vida, trate com quem decide).

Uma das grandes frustrações dos profissionais de TI é nunca serem capazes de discutir com “quem decide”.

O Arquiteto, por outro lado, tende a ser um interlocutor privilegiado de quem decide, desde que a prática de Arquitetura em sua organização seja levada a sério.

Arquitetura Corporativa tem tudo a ver com a Estratégia. É claro que há muitas empresas que alegam praticar Arquitetura Corporativa, mas que mal e mal praticam Arquitetura de TI, a milhares de quilômetros das questões estratégicas da organização. Mesmo que este seja o seu caso, é difícil imaginar qualquer profissional de TI mais próximo das questões que realmente contam na empresa do que o Arquiteto. Se há alguém de TI capaz de “subir a escada” e chegar a discutir Estratégia, esse alguém é o Arquiteto (observe-se que estou me referindo e me dirigindo aos profissionais de TI: nada impede que o arquiteto venha de uma experiência profissional completamente diferente).

Enfim, poderíamos listar muitas outras boas razões pelas quais um profissional deva considerar seriamente a possibilidade de tornar-se um Arquiteto Corporativo. Mas acredito que tenhamos listado aqui algumas das mais importantes delas. Espero ter convencido alguém!

No próximo “fascículo”, trataremos da questão de “por onde começar”, ou seja, o que é necessário para alguém tornar-se um Arquiteto Corporativo.

Clique aqui para ler o próximo artigo da série

Links

Outros artigos da série:

Parte I: Introdução

Parte II: 5 Razões para se tornar um Arquiteto Corporativo

Parte III: Por onde começar?

Parte IV: Frameworks de Arquitetura: Zachman

Parte V: Frameworks de Arquitetura: TOGAF

Outros artigos de Arquitetura Corporativa

Arquitetura Corporativa e Gestão de Portfolio de Projetos

Os 3 mal-estares do Planejamento Estratégico

Arquiteto Corporativo: Profissional do Futuro – Introdução

Participei, recentemente, de uma discussão em um fórum de BPM na Internet em que a discussão girava em torno de vários papéis profissionais propostos e esperados nas empresas hoje em dia, mas sobre os quais existe pouco consenso.

Tomemos, por exemplo, os papéis de Analista de Negócios e Analista de Processos. Há quem diga que os dois nomes servem para a mesma função, há quem diga o contrário.

O Analista de Processos, por exemplo, parece ser um herdeiro do tradicional Analista de O&M (que ainda existe em empresas mais tradicionais). Ele seria um especialista em modelagem de processos, notações de modelagem (como a BPMN), técnicas de melhoria de processos etc.

O Analista de Negócios, por outro lado, seria alguém próximo às áreas de negócio da organização, ou seja, alguém que “faz a ponte” entre as necessidades que as áreas de negócio têm em relação à TI e, por outro lado, esta última. Assim, ele é alguém que conhece bem o negócio da empresa e tem um verniz de TI suficiente para saber o que dá para fazer e o que é inviável, mesmo sem ser um especialista em tecnologia.

Na discussão a que me referi no início deste artigo, a disputa se dava em relação à ordem em que diversos “especialistas” (como os referidos analistas de negócios e de processos, mais os velhos e bons analistas de sistemas) deveriam “aparecer” no processo de melhoria e automação de processos de negócio na organização. Um dos participantes, muito apropriadamente, levantou a questão de se não seria bom haver um único “ponto focal”, um único contato para todos os envolvidos no processo, usuários de negócio, desenvolvedores etc. Ele mesmo levantava a hipótese de se um tal “Arquiteto de Soluções” não seria esta pessoa.

De  fato, a ideia de que precisamos de um “Arquiteto” está cada vez mais aceita, embora ainda não esteja claro de que tipo de Arquiteto estejamos falando, nem de que tipo de Arquitetura ele se ocupe.

O fato é que a Arquitetura Corporativa (ou Arquitetura Empresarial, numa outra tradução frequente) é um assunto que se torna cada vez mais presente, fazendo com que a figura do Arquiteto também ganhe foco.

Este artigo inaugura uma sequência de 10 “fascículos” que procurarão detalhar essa figura tão nova, o Arquiteto Corporativo. Tem, também, a pretensão de defender a ideia de que esta é uma das mais “quentes” profissões nas áreas de TI e Negócios para os próximos anos.

Procuraremos publicar, a cada poucos dias, um “capítulo” dessa história, sendo o seguinte o nosso plano:

  1. Introdução à Serie (este artigo)
  2. 5 razões para se tornar um Arquiteto
  3. Por onde começar?
  4. Frameworks de Arquitetura – Zachman
  5. Frameworks de Arquitetura – TOGAF
  6. Os diferentes tipos de arquitetos
  7. O Arquiteto e os outros profissionais
  8. O skillset do Arquiteto
  9. Certificações
  10. Conclusão / resumo / próximos passos

Clique aqui para ler o próximo artigo da série

Esperamos que, ao final, tenhamos um artigo mais longo que poderá ser lido por inteiro de uma só vez, quem sabe um pequeno e-book!

Boa Leitura!

Links

Outros artigos da série:

Parte I: Introdução

Parte II: 5 Razões para se tornar um Arquiteto Corporativo

Parte III: Por onde começar?

Parte IV: Frameworks de Arquitetura: Zachman

Parte V: Frameworks de Arquitetura: TOGAF

Outros artigos de Arquitetura Corporativa

Arquitetura Corporativa e Gestão de Portfolio de Projetos

Os 3 mal-estares do Planejamento Estratégico

5 razões para se tornar um Arquiteto

Gartner sobre Arquitetura Corporativa na Info Corporate
Artigo Gartner - Info Corporate
Artigo Gartner – Info Corporate

Alguns cínicos costumam dizer que, quando um assunto chega às grandes publicações, é porque já está no passado.

Embora isto seja evidentemente exagerado, é auspicioso ver que o tema da Arquitetura Corporativa (ou Empresarial, como querem alguns) começa a aparecer na “grande mídia”, pelo menos na especializada, neste caso representada pela revista Info Corporate.

Em seus boletins periódicos, a revista sempre destaca um artigo (normalmente traduzido) do Gartner, cujas opiniões, sabemos bem, são muito respeitadas por estas plagas. É uma boa notícia que o nosso assunto tenha sido objeto de tal honraria duas vezes em menos de dois meses!

O primeiro – A arquitetura corporativa traz valor ao negócio? – saiu no início de Junho. Infelizmente, foi muito mal traduzido (automaticamente?), de modo que quem preferir pode ler o original aqui.

O segundo – A Arquitetura Corporativa em tempos de desafios econômicos – saiu hoje e, felizmente, está traduzido decentemente.

Os dois tem em comum uma questão muito atual: vale a pena investir em Arquitetura Corporativa em tempos de crise econômica? Não seria a Arquitetura mais um desses “luxos” que entram na primeira lista de cortes de custos?

Continue reading →

Arquitetura Corporativa e Gestão de Portfolio de Projetos

Cada vez mais, as organizações apreciam as vantagens de implantar um Escritório de Projetos (PMO – Project Management Office) e de incluir nas atribuições deste órgão a tarefa de gerenciar o portfolio de projetos da organização.

A Gestão de Portfolio de Projetos é a disciplina (processos, técnicas e ferramentas) através da qual a organização é capaz de obter e documentar informações sobre os projetos em curso e programados ou demandados, e avaliar e comparar esses projetos entre si, em termos de um conjunto de aspectos, tais como alinhamento com o negócio, risco, retorno e uso de recursos. Com base nessa avaliação, o PMO pode classificar os projetos propostos, priorizando-os e alocando recursos proporcionais a sua importância a cada um, indicada pela classificação. Além disso, a Gestão de Portfolio de Projetos inclui práticas e ferramentas para monitorar e controlar os projetos coletivamente.

Benefícios da Gestão de Portfolio de Projetos

Existem inúmeras vantagens em tratar os projetos da organização como uma carteira ou portfólio. Alguns dos principais são os seguintes:

  • Eliminação de projetos duplicados. Projetos idênticos, ou muito similares, sendo conduzidos em duas ou mais áreas na empresa podem ser fundidos em um só, reduzindo custos e evitando incompatibilidades no futuro.
  • Combinação de projetos gerando economias de escala. Projetos que, embora não sejam idênticos, fazem sentido de serem executados juntos, pela mesma equipe e próximos no tempo. Um exemplo seriam projetos que produzem muitas entradas um para o outro.
  • Visão clara da interdependência entre projetos. É mais fácil perceber quais saídas do projeto A devem ser entradas para o projeto B e vice-versa.
  • Orienta a coordenação no tempo de diferentes projetos: o que deve acontecer no projeto A antes que se possa executar a tarefa X no projeto B.
  • Redução da prioridade de projetos necessários, mas menos importantes ou urgentes. Ao comparar o escopo do projeto com as necessidades estratégicas da organização, é possível detectar quais projetos podem ser deixados para depois, quando houver mais recursos disponíveis.
  • Aumento da prioridade de projetos estratégicos, mas de baixa visibilidade. Da mesma forma, o exame da relevância do projeto para o cumprimento das metas estratégicas pode levar à priorização e alocação de recursos adicionais a um projeto cuja visibilidade esteja baixa, talvez por falta de patrocinadores poderosos.
  • Otimização da alocação de recursos e talentos. A Gestão de Portfolio de Projetos provê orientação na formação de equipes, usando as habilidades das pessoas onde contam mais. Se existe alguém na organização que é um expert em uma das fases-padrão dos projetos normalmente executados, por que esta pessoa deveria estar “fixa” em uma equipe que pega um projeto após o outro, participando também das atividades nas quais não é tão bom assim? Se João é um ótimo especificador de requisitos, mas um desenvolvedor apenas mediano, que sentido tem ele fazer tudo na equipe? Não é melhor que ele especifique os requisitos no projeto A, depois vá fazer o mesmo no projeto B e assim por diante? Com a visão global que a Gestão de Portfolio dá, é possível planejar melhor o emprego dos especialistas nos diversos projetos.
  • Visão clara do que deve ser feito pela “prata-da-casa” e o que pode ou deve ser terceirizado. Projetos críticos que exijam a participação intensa de pessoal interno são mais facilmente identificados, de modo que podemos deixar os outros projetos como candidatos à terceirização.
  • Identificação de necessidades de contratação e treinamento. Como a Gestão de Portfolio provê uma visão de médio a longo prazo para os projetos da organização, é possível identificar com bastante antecedência quais serão as competências necessárias no momento em que os projetos começarem. Nada de treinar pessoas depois que o projeto já começou! Da mesma forma, é possível antecipar se será necessário trazer gente nova para o time.

Limitações da Gestão de Portfolios de Projetos

Embora tudo isso seja verdade, a Gestão de Portfolio de Projetos (GPP) tem também suas limitações. A mais importante delas é que a GPP trata da priorização de projetos depois que foram sugeridos ou requisitados, ou mesmo quando já estão em andamento. Isto significa que nada garante que não sejam outros os projetos realmente necessários. A GPP tipicamente não produz sugestões de projetos, ela apenas analisa aqueles que lhe são propostos. E, como diz aquele velho ditado, “garbage in, garbage out”, ou seja, se entrar lixo, do outro lado do processo não há como sair algo diferente… E se a organização não tiver um processo para produzir a lista de projetos de que ela realmente precisa? Afinal, pode ser que os projetos necessários nem tenham sido sugeridos ou vislumbrados por ninguém…

Outra importante limitação da Gestão de Portfolio de Projetos é que a comparação se dá entre os projetos que estão no portfólio, mas aquilo que já existe na organização é desconsiderado. Suponha que o PMO detecte dois projetos com escopos quase idênticos, sendo conduzidos em diferentes departamentos. A Gestão de Portfolio de Projetos pode ajudar a evitar essa duplicidade, fundindo os projetos. Suponha agora que o escopo do projeto envolve produzir algo que já foi produzido antes por um terceiro projeto em um terceiro departamento, sendo que o projeto terminou e entregou o produto há, digamos, dois anos. A GPP não vai pegar isso. Embora se tenha evitado a redundância de dois projetos simultâneos fazendo a mesma coisa, não há como evitar que um projeto produza algo que já existe na organização.

Arquitetura Corporativa e Gestão do Portfolio de Projetos

É aqui que entra a Arquitetura Corporativa[1]. É ela quem dá condições de complementar as práticas de GPP, superando as limitações citadas.

Como sabe o leitor, A Arquitetura Empresarial mapeia a organização inteira: começa com a Estratégia, prossegue com o mapeamento dos processos de negócio e em como esses processos executam (ou deixam de executar) a Estratégia; passa então para os Sistemas de Informação que automatizam (ou não) esses processos de negócio (bem ou mal) e termina identificando a infraestrutura tecnológica disponível para a execução desses sistemas. Além disso, o processo de Arquitetura Corporativa mapeia não só o que existe hoje (Arquitetura AS-IS), mas também o que é necessário no futuro para que a Estratégia da organização possa ser implementada (Arquitetura TO-BE). Por fim, o processo também leva os arquitetos a fazerem a análise entre o que existe hoje e o que deveria existir (gap analysis), e é justamente desta análise que deve sair o portfólio dos projetos necessários para que a organização consiga implementar sua estratégia. Em outras palavras, são esses os projetos de que a empresa precisa. Inversamente, qualquer projeto proposto que não puder explicar como é que ele ajuda a organização a ir de onde ela está para onde ela quer chegar não merece ser incluído no portfolio. Ou seja, a Arquitetura Corporativa permite identificar os projetos realmente necessários, coisa que a Gestão de Portfolio de Projetos sozinha não é capaz de fazer.

Além disso, a Arquitetura Empresarial provê ao PMO as informações necessárias para responder a duas perguntas essenciais para a avaliação de projetos:

  1. O que este projeto pretende produzir já existe em algum outro lugar na organização? Ou seja, a Arquitetura Corporativa resolve o segundo problema mencionado antes, a questão de saber se um projeto não é redundante com outro projeto que já tenha terminado e já esteja “fora” do portfólio.
  2. O que este projeto pretende produzir aparece em alguma arquitetura futura (TO-BE) da organização? Se sim, o projeto deveria estar no portfólio de projetos da Arquitetura, ou então ser combinado com algum projeto que já esteja lá. Se não, das duas, uma: ou o projeto não é necessário e não deve ser executado; ou ele é, sim, necessário, e é a Arquitetura que está incompleta e deve ser atualizada.

Essas são apenas duas das formas pelas quais a Arquitetura Empresarial ajuda e completa a Gestão de Portfolios, mas existem várias outras. Uma que não é possível deixar de mencionar é a capacidade que a Arquitetura Corporativa dá ao PMO de avaliar corretamente o impacto e o risco de um projeto, ao disponibilizar informação sobre como os vários elementos da organização estão interligados. Sem Arquitetura, esse tipo de análise acaba sendo pouco mais que “chute”, e a sua aproximação em reação à realidade vai depender muito de quem estava disponível no momento para fazer a análise. Discutiremos esse aspecto da Arquitetura Corporativa em um próximo artigo.

[1] Não existe ainda uma tradução universalmente aceita para a expressão em inglês “Enterprise Architecture”. De modo geral, a expressão vem sendo traduzida tanto como Arquitetura Corporativa quanto Arquitetura Empresarial. Usaremos as duas expressões indistintamente.

Os 3 mal-estares do Planejamento Estratégico

No segundo semestre da cada ano, muitas empresas realizam seu ritual periódico de planejamento estratégico. Os executivos reúnem-se para revisar o planejamento em curso e estabelecer objetivos e metas para o próximo período.

Cada executivo, naturalmente, conhece relativamente bem os detalhes da operação de sua área, mas, devido às pressões do dia-a-dia e às inevitáveis dificuldades de comunicação, seu conhecimento a respeito das demais áreas é quase sempre bastante fragmentário. Mesmo no que se refere a sua própria área, às vezes o executivo dispõe apenas de alguns indicadores mais ou menos confiáveis. Sobre a empresa como um todo, pode acontecer de ele ter que se dirigir à reunião com pouco mais do que os últimos balancetes. Assim, não é incomum que esses executivos vão para as reuniões de planejamento estratégico com a desconfortável sensação de que serão chamados a tomar decisões estratégicas com base em informações em quantidade insuficiente e de qualidade duvidosa.

O processo de planejamento utiliza diversas ferramentas para ordenar e guiar o pensamento e as discussões. Análises SWOT, modelos de referência como a Cadeia de Valor de Michael Porter e o Balanced Scorecard estão entre as ferramentas mais populares. Às vezes, estão disponíveis dados de produção ou de mercado em ferramentas de Business Intelligence. Aqui ocorre o segundo mal-estar. Muitas dessas técnicas e ferramentas produzem resultados tão bons quanto os dados de entrada disponíveis. Ou seja, se a informação de entrada é incompleta ou inadequada, o resultado da aplicação das técnicas pode deixar a desejar.

Tomemos, por exemplo, a análise SWOT. O “S” e o “W” dizem respeito forças e fraquezas internas da organização. Pode haver pouca informação confiável a este respeito. Durante as reuniões de planejamento estratégico, idéias são colocadas na mesa, hipóteses são levantadas e opções são discutidas. Infelizmente, a discussão sobre as opções muitas vezes é feita com base em hipóteses e pressupostos não verificáveis no momento das reuniões, sendo que, o que é pior, trata-se de informação disponível na empresa, mas não se sabe onde nem com quem!

É costume referir-se à Estratégia como “olhar a floresta em vez de olhar as árvores”. O problema é que, no mundo real, não dá para entender a floresta sem conhecer bem as árvores também. Grandes decisões estratégicas podem ser técnica ou economicamente inviáveis quando sua implementação é desdobrada em detalhes.

Ao final do processo de planejamento estratégico, o executivo sai com um conjunto de metas que precisa alcançar em sua área. Neste momento, ocorre o terceiro mal-estar, pois é freqüente que o executivo não saiba por onde começar. Afinal, é sabido que comunicar a estratégia e transformá-la em operação no dia-a-dia é um dos maiores desafios das organizações. Na falta de melhores instrumentos, o executivo acaba se restringindo a cobrar “mais empenho”. Mas a implementação da estratégia tem que ser mais do que “vamos trabalhar mais duro”.

Um exemplo concreto

 Suponhamos que a empresa esteja enfrentando um ambiente competitivo que se acirrou no último período. Novos entrantes muito ágeis surgiram, e os concorrentes tradicionais responderam de forma agressiva, levando a uma guerra de preços que reduziu a rentabilidade de todas as empresas no setor. Além disso, nossa empresa-exemplo, por não ter respondido a tempo, acabou por perder participação de mercado.

Vamos supor que, no momento do planejamento estratégico, a nossa empresa disponha de informações razoáveis sobre o mercado. Ela precisa decidir o que fazer. Ao longo das discussões, surgem três opções estratégicas preferidas:

  1. Reduzir preços também, para recuperar o market-share perdido, reduzindo custos ao mesmo tempo para preservar a rentabilidade;
  2. Investir na diferenciação da oferta da empresa, sem alterar significativamente os preços, com foco em fidelização dos clientes atuais e expansão da base;
  3. Entrar em novos segmentos de mercado, pouco explorados pelos concorrentes.

Como decidir entre estas opções? Na falta de informação completa e confiável sobre as forças e fraquezas internas da organização, é muito difícil.

Seria necessário responder a perguntas como:

  • Temos espaço para reduções significativas de custos? Quanto custam nossos processos de negócio? Eles podem ser racionalizados de modo a gerar reduções significativas de custo? Quanto vai custar para reduzirmos os custos de nossos processos? Isso pode ser feito em um horizonte de tempo viável?
  • Se optarmos pela estratégia de diferenciação, quais os nossos atuais processos de negócio que precisam ser revistos? Os processos, como são hoje, dão conta de sustentar esta estratégia? Se tivermos que mudar esses processos, quais os impactos? Que processos relacionados precisariam ser revistos? Nossos Sistemas de Informação atuais dão conta dos novos processos necessários? Vamos precisar de novos sistemas? Podemos alterar os atuais? Quanto tempo vai levar e quanto vai custar? Nosso time de colaboradores possui as competências necessárias para sustentar esta nova estratégia? Podem ser capacitados? Quanto tempo vai levar e quanto vai custar?
  • Da mesma forma, se optarmos por atacar novos segmentos de mercado, de que novos processos, sistemas e competências precisaremos?

Esses são apenas alguns exemplos de perguntas cujas respostas são essenciais para a tomada de decisão informada em um processo de planejamento estratégico. Mas essas respostas, muitas vezes, estão escondidas em lugares que os executivos planejadores não sabem nem mesmo por onde começar a procurar.

Arquitetura Corporativa

A Arquitetura Corporativa procura dar respostas a essas perguntas. Na verdade, não se trata de um conceito especialmente complexo. Ao contrário, conceitualmente é bastante simples.

O dono de uma casa precisa ter as plantas da Arquitetura de sua casa disponíveis e atualizadas para poder fazer reformas sem “furar canos”, “tomar choques” ou, o que é pior, atingir um pilar estrutural ao derrubar uma parede.

Os executivos de uma empresa, da mesma forma, precisam de um conjunto de “plantas” que descreva a empresa para que possam empreender “reformas” sabendo antecipadamente o que deve ser feito e os custos e riscos envolvidos.

Infelizmente, essas “plantas” da organização normalmente não estão disponíveis. Pior ainda, “reformar” a empresa é uma necessidade muito mais freqüente do que reformar uma casa, e a empresa típica está sempre com algum tipo de “reforma” em curso, seja para atender mudanças na estratégia, na legislação ou mesmo de necessidades puramente operacionais. Essas “reformas” incluem mudanças em metas, nos processos de negócio, nas estruturas organizacionais, em sistemas de informação e na infra-estrutura física da empresa (reformas stricto sensu).

A Arquitetura Corporativa se propõe desenhar e manter disponíveis e atualizadas essas plantas, de modo que o time executivo possa tomar decisões baseadas em informação consistente, sendo capaz de avaliar custos, prazos, riscos e outros tipos de impactos ao empreender mudanças na estratégia, por exemplo.

A Arquitetura Corporativa nada mais é, portanto, do que um conjunto de modelos descritivos da organização (“plantas”) armazenados em um repositório centralizado, acompanhado de estruturas organizacionais e processos que garantam que esta informação se mantém sempre atualizada e relevante.

Nos próximos artigos, detalharemos diversos aspectos relacionados com a Arquitetura Corporativa, como as diferentes formas em que a informação pode ser armazenada, como iniciar um projeto para implantação de Arquitetura Corporativa, sua relação com a Governança Corporativa e a Governança de TI, entre outros assuntos.

Uma Lição de Gestão do Conhecimento da Segunda Guerra Mundial

A História da Segunda Guerra Mundial nos dá um exemplo da diferença que pode fazer a aplicação de alguns conceitos, hoje bem conhecidos, da Gestão de Conhecimentos, e a atenção aos aspectos culturais da organização.

Quem se interessa por esse período histórico e, especialmente, pela Guerra Aérea e Aeronaval, tanto na Europa quanto no Pacífico, espanta-se, a principio, ao ver o desempenho relativo dos pilotos de caça norte-americanos, comparados aos japoneses e alemães. Esses últimos parecem ter tido desempenho muito melhor, apesar de terem perdido a guerra.

Um “Ás” era definido, por cada Força Aérea, como um piloto de caça que tivesse obtido um número de “vitórias” superior a um nível pré-determinado. Uma “vitória” é a derrubada confirmada de um avião inimigo de qualquer tipo (um bombardeiro, um transporte, outro caça ou qualquer outra aeronave militar).

Quando se lê a respeito dos ases alemães e japoneses, é freqüente vermos referências a números de vitórias superiores a 200 ou 300. Já um piloto americano era considerado um “ás” com 10 vitórias. Olhando assim, parece ser um ás meio “fajuto”, não é?

O fato é que os americanos adotaram uma política muito inteligente, que era a de condecorar o piloto como ás quando ele obtivesse sua décima vitória, e enviá-lo de volta aos Estados Unidos para ser instrutor de combate aéreo. Promoção, medalha, fanfarra, festa, tapinhas nas costas e “go back home”. Os pilotos nem sempre gostavam disso, pois, para muitos, isso era como uma “aposentadoria compulsória”, afastando-os das glórias do combate no front.

Essa política, porém, mostrou-se extremamente acertada, a ponto de Matsuo Fuchida – o comandante das forças japonesas que atacaram Pearl Harbor e da força aérea embarcada nos porta-aviões japoneses até a batalha de Midway – dizer que esta foi uma das razões para a derrota do Japão na Guerra. O livro de Fuchida serviu de base para o roteiro do clássico de Hollywood “Midway”, com Charlton Heston. O próprio Fuchida aparece como personagem no filme.

O Japão havia adotado o que Fuchida chamou de “Política dos Ases”, em que os pilotos mais experientes e habilidosos eram mantidos nos porta-aviões, combatendo até a morte. Como resultado, não havia instrutores experientes no Japão para treinar novos pilotos. No fim da Guerra, havia pouquíssimos pilotos japoneses experientes. Os pilotos Kamikase, aliás, tinham um treinamento de vôo de duas semanas, e eram os piores entre os alunos-piloto (os que apresentavam alguma habilidade eram destacados para missões “normais” de combate).

Assim, os EUA deram um exemplo de “transformação do conhecimento tácito em tácito”, para usar o modelo de Nonaka e Takeuchi (1997). Segundo Polany (1966) o conhecimento pode ser tácito ou explícito. O conhecimento tácito é pessoal, específico ao contexto e difícil de ser formulado e comunicado. Uma ótima cozinheira pode não ser capaz de explicar formalmente o que é que faz com que seus quitutes sejam tão bons. O conhecimento explícito, por sua vez, é codificado, transmissível em linguagem formal e sistemática. Pode, por exemplo, ser adquirido em livros. Para Nonaka e Takeuchi, os dois tipos de conhecimento podem ser “convertidos”, ou transmitidos, um para outro, de modos distintos. A conversão de tácito para tácito é chamada pelos autores de “socialização”, que é um processo de compartilhamento de experiências. É exatamente o caso aqui, o ensino prático de pilotagem de aviões.

A instrução de vôo é um exemplo límpido deste tipo de transmissão de conhecimentos. Por mais que o aluno-piloto leia manuais, aprende a voar voando. E o instrutor é essencial nesse processo, quando a demonstração e a imitação são os fatores mais importantes.

Nada substitui um instrutor experiente em combate numa situação dessas. O fato de os novos caçadores americanos terem sido ensinados por pilotos de caça excepcionais pode ter feito uma enorme diferença na Guerra.

Não deixa de ser irônico que tenham sido dois autores japoneses a destacar o bom gerenciamento do conhecimento tácito como a causa principal da superioridade de algumas empresas japonesas sobre americanas, em termos de inovação, uma vez que o episódio que estamos considerando trata justamente da superioridade americana nessa empreitada sobre os japoneses, na Guerra, através exatamente do conhecimento tácito.

Cultura

Não seria exagerado afirmar que as Culturas Organizacionais das diferentes forças aéreas tiveram influência decisiva na política para com os ases e, portanto, nos seus resultados durante a guerra.

A Cultura, entre outras coisas, diz respeito às crenças e valores compartilhados pelos membros da organização. Na carreira militar, o “caçador”, ou seja, o piloto de caça, é normalmente visto como um herói solitário e, de fato, é comum que esses pilotos sejam frequentemente individualistas, de forma um pouco paradoxal, já que as Forças Armadas são, essencialmente, um empreendimento baseado do trabalho em equipe.

A Cultura das forças aéreas japonesa e alemã era de forte individualismo, e o “estrelismo” dos ases era incentivado pelos altos escalões. Os ases eram propostos como heróis nacionais e tratados como celebridades, como exemplo para os concidadãos. Havia, inclusive, um incentivo insano à competição interna, em que os pilotos procuravam em primeiro lugar obter mais vitórias do que os demais pilotos do esquadrão, às vezes levando-os a colocar isso acima dos objetivos ou mesmo da segurança da missão.

Na força americana, sem matar totalmente essa característica, havia muito maior atenção aos valores de trabalho em equipe e transmissão de conhecimento e experiência. É claro que existia aí também a competição, mas sua importância era muito menor, e tudo era feito em um clima de camaradagem.

Lições

Este exemplo serve para ilustrar como a Cultura Organizacional pode influenciar esforços de Gestão de Conhecimento nas organizações. É praticamente impossível fazer dar certo um esforço desse tipo se a cultura for, por exemplo, de incentivo ao individualismo e à competição interna. Se minha empresa me incentiva a ver meu colega de trabalho como um concorrente, porque eu pararia o que eu estou fazendo para gastar meu precioso tempo para, ainda por cima, passar para meu concorrente (o colega!) o meu conhecimento?

Quando falo de Gestão do Conhecimento, não me refiro somente a esforços “explícitos” nesse sentido, como, por exemplo, um “Projeto de Portal Corporativa com Ferramentas de Colaboração” (Wiki, por exemplo).  Quase todos os grandes projetos que as empresas estão desenvolvendo hoje, como implantação de CMMI, COBIT, ITIL, PMO e que tais, possuem um imenso componente de Gestão do Conhecimento. Você não pode esperar por um “Projeto de Gestão de Conhecimento” para colocar essas práticas em ação se você estiver implantando, por exemplo, melhoria de processos segundo o CMMI. A definição de um processo puro e simples, por exemplo, não garante seu entendimento e utilização. Novos colaboradores aprendem fazendo e, principalmente, através do exemplo dos colegas mais antigos. Ou seja, socialização do conhecimento. E, sem isso, evidentemente, não teremos a institucionalização, requerida pelo modelo.

A Cultura se manifesta em artefatos visíveis. Não basta um belo discurso de incentivo ao compartilhamento do conhecimento. As práticas de Gestão de Pessoas, por exemplo, tem que estar alinhadas com esses valores. Se, por exemplo, os critérios para avaliação de desempenho, promoção e remuneração variável estiverem focados no desempenho individual do colaborador, ele receberá da organização a mensagem de que o discurso é “só pra inglês ver”. Portanto, esforços de Gestão do Conhecimento só dão certo com uma Cultura adequada, que se manifeste em políticas e práticas de Gestão de Pessoas consistentes com ela. Ao escolher alguém para promoção, a empresa tem que levar em conta o quanto ele se dedica a compartilhar seus conhecimentos com os colegas. Na hora de conceder bônus, o tempo e o esforço dedicados a ensinar os colegas têm que ser levados em conta.

Ases solitários e instrutores

Outra lição importante aqui deveria ser absorvida pelas empresas. Quando o conhecimento tácito está envolvido, é muito mais produtivo que os trabalhadores mais experientes gastem seu tempo instruindo os mais novos do que apenas executando suas tarefas. Um Desenvolvedor experiente, por exemplo, pode aumentar a qualidade do desenvolvimento de software em todas as equipes de uma empresa, caso seja destacado para o “peer review” do trabalho de todos. O resultado final será o aumento da qualidade no trabalho das diversas equipes. Caso este expert seja mantido a cuidar apenas do “seu sistema”, este poderá alcançar enorme qualidade, mas apenas ele. Poderemos ter um software fantástico junto a todos os outros de qualidade medíocre. Caso o expert seja destacado para revisar o trabalho dos outros, poderemos ter todas as equipes produzindo software de boa qualidade, mesmo que nenhum deles seja excepcional. Na média, o resultado é sempre melhor. Mas é difícil encontrar empresas dispostas a abrir mão do trabalho especializado de um expert, transformando-o em formador das novas gerações de trabalhadores. A “Política dos Ases” japonesa, como se vê, fez escola.

Publicado originalmente em 1-11-2002

Revisado e ampliado em 18-9-2007

 

Referências:

NONAKA, I. e Takeuchi, H. Criação de Conhecimento na Empresa. São Paulo, Campus,1997.

POLANY, M. Personal Knowledge. Chicago, University of Chicago Press, 1958.

FUCHIDA, M. e Okumiya, M. Midway. São Paulo, Flamboyant, 1967.