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:

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

É 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

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:

• Conhecimentos gerais de Gerenciamento de Projetos, tais como os presentes no Guia PMBOK®.
• Técnicas de Análise e Gestão da Cultura Organizacional e das Relações de Poder. Embora essenciais para todo gerente de projetos, essa última são fundamentais para o Arquiteto Corporativo, dado que seu trabalho consiste em grande parte em negociação com vários stakeholders simultaneamente (leia também nosso artigo Gestão do Conhecimento e Cultura Organizacional: Uma Lição da II Guerra).

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

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

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