O Curso Oficial (Accredited) de TOGAF 9 vem sendo ministrado, desde Janeiro, por mim.
Como o leitor sabe, o curso é ministrado pela Architecting the Enterprise (AtE), a principal consultoria em TOGAF do mundo, em parceria com a GNOSIS.
Participei, no fim do ano passado, do processo de credenciamento de instrutores da AtE, tornando-me o primeiro (e, até agora o único) instrutor no Brasil credenciado a ministrar o curso. Desde janeiro já ministramos duas turmas, no Rio de Janeiro e em São Paulo.
O próximo passo é a tradução dos materiais para o Português.
Comecei neste mês a ministrar a disciplina Cultura e Poder em Projetos para a 10a e a 11a turmas do curso de pós-graduação em Gerenciamento de Projetos do SENAC-SP. Ministro esta disciplina desde 2000, quando tivemos as primeiras turmas do curso e, desde então, ela vem sendo avaliada pelos alunos como uma das melhores do curso. Isto se deve ao fato de que o conteúdo abordado – Sociologia e Ciência Política aplicados às Organizações e aos Projetos – é visto pelos alunos como um complemento fundamental aos temas vistos nas demais disciplinas do curso, que versam principalmente sobre as áreas de conhecimento do Guia PMBOK. A idéia é alertar aos alunos para o fato de que um projeto “tecnicamente perfeito” – ou seja, empregando as boas práticas do PMBOK – nem por isso tem seu sucesso garantido, já que a atenção aos aspectos da Cultura Organizacional e das Relações de Poder ali existentes é fundamental para garantir o sucesso do projeto.
O conteúdo da disciplina é o mesmo do curso homônimo que ministramos na Gnosis.
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
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.
Teremos mais uma turma de nosso curso de Arquitetura Corporativa no final deste mês. Como sempre, o curso detalha os frameworks Zachman e TOGAF 9 e inclui todo o conteúdo necessário para a certificação do Open Group.
Neste quarto artigo da série “Arquiteto Corporativo: Profissão do Futuro”, detalhamos o framework mais famoso do assunto: o Zachman. No próximo artigo, detalharemos o TOGAF.
É 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.
Ai estamos com mais uma parte da série. Deste vez, listamos os principais conhecimentos necessários ao Arquiteto Corporativo. Boa leitura e não dei de comentar e deixar sua opinião!
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®.
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!
Uma das coisas mais desagradáveis para quem trabalha muito com arquivos PDF, especialmente como fontes de referência, é a incapacidade de marcar texto e acrescentar anotações. O formato PDF gosta de se apresentar como a versão eletrônica do documento de papel, mas, para que isso seja verdade, fica faltando a característica mais útil e importante de um documento de papel: a possibilidade de marcar os trechos que nos interessam com uma caneta amarela e de acrescentar notas e comentários nas margens. A impossibilidade de fazer isso sempre foi a principal causa de meu pouco amor pelo Acrobat Reader.
Mas “seus problemas acabaram”! O PDF XChange Viewer permite exatamente isso, e muitas outras coisas, em sua versão free! E quem tiver necessidades maiores de manipulação de arquivos PDF pode adquirir uma licença a custo infinitamente inferior aos cobrados pela Adobe.
Só achei essa pérola e estou usando desde ontem, mas já me apaixonei…
Não sei como sobrevivi até hoje sem essa ferramenta! 🙂
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png?w=640)