Irei apresentar um pouco do Framework TOGAF que eu gosto de dizer “processo”, para arquitetura corporativa.
O framework arquitetural do Open Group é mais conhecido pelo seu acrônimo: TOGAF. O TOGAF é de propriedade do Open Group [19]. A Figura 5 apresenta a visão do TOGAF de uma arquitetura corporativa.
Figura 5. Arquitetura corporativa do TOGAF
Como apresentado na figura, o TOGAF divide uma arquitetura corporativa em quatro categorias, como segue:
- Arquitetura de negócioDescreve os processos que o negócio usa para cumprir suas metas;
- Arquitetura de aplicativoDescreve como aplicativos específicos são programados e como interagem;
- Arquitetura de dadosDescreve como os armazenamentos de dados são organizados e acessados;
- Arquitetura técnicaDescreve as infra-estruturas de hardware e software que suportam os aplicativos e suas interações.
O TOGAF descreve a si próprio como um “framework”, mas a parte mais importante do TOGAF é o método de desenvolvimento da arquitetura, mais conhecido como ADM. O ADM é uma receita para a criação da arquitetura. Receitas podem ser categorizadas como processos. Considerando que o ADM é a parte mais visível do TOGAF, coloquei o TOGAF na categoria geral de processo arquitetural, em lugar de framework arquitetural (como o Open Group descreve o TOGAF) ou de metodologia (como o ADM é descrito).
Considerado como processo arquitetural, o TOGAF complementa a rede Zachman a qual, recordo, categorizei como taxonomia arquitetural. A rede Zachman diz como categorizar seus artefatos. O TOGAF oferece um processo para criá-los.
O TOGAF observa o mundo da arquitetura corporativa como um continuum de arquiteturas, variando de extremamente genérico para altamente específico. Continuum corporativo é a denominação dada a esse continuum. Observa o processo de criação de uma arquitetura corporativa específica, como o sistema MAM-EA, passando do genérico para o específico. O ADM do TOGAF oferece um processo para encaminhar este movimento do genérico para o específico.
O TOGAF denomina as arquiteturas mais genéricas de arquiteturas de fundamento. Estes são princípios arquiteturais que, teoricamente, podem ser usados por qualquer organização de TI do universo.
O TOGAF denomina o próximo nível de especificidade de arquiteturas de sistemas comuns. Estes são princípios que ninguém esperaria ver em muitos, mas, talvez, não todos os tipos de empresas.
O TOGAF denomina o próximo nível de especificidade de arquiteturas setoriais. Estes são princípios específicos de muitas empresas, parte do mesmo domínio como, no nosso estudo de caso MedAMore, o de todas as empresas farmacêuticas.
O TOGAF denomina o nível mais específico de arquiteturas organizacionais. Essas são as arquiteturas específicas de uma determinada empresa, como a MedAMore.
A Figura 6 apresenta a relação entre o continuum corporativo e o método de desenvolvimento da arquitetura (ADM).
Figura 6. O continuum corporativo do TOGAF
O TOGAF define as várias bases de conhecimento que residem na arquitetura de fundamento. Duas que poderão cruzar o seu caminho são o modelo de referência técnica (TRM) e a base de informações-padrão (SIB). O TRM é uma descrição sugerida de uma arquitetura de TI genérica. A SIB é uma coleção de padrões e pseudopadrões que o Open Group recomenda considerar na construção de uma arquitetura de TI.
O TOGAF apresenta o TRM e a SIB como sugestões; nenhum deles é necessário. No meu entender, o TRM e a SIB têm falhas pela mesma razão: são tendenciosos em favor da portabilidade, em detrimento da interoperabilidade e da autonomia do aplicativo. Considero esta uma visão desatualizada das arquiteturas técnicas.
Para uma organização como a MedAMore, o TOGAF em grande parte reduz-se ao método de desenvolvimento da arquitetura (ADM). Os indivíduos da MedAMore ficarão expostos ao continuum corporativo, à SIB e ao TRM (assim como a alguns outros recursos do TOGAF) e por isso eu os trouxe para esta discussão. Todavia, a experiência diária de criar uma arquitetura corporativa será dirigida pelo ADM; a Figura 7 mostra uma visão de alto nível dessa criação.
Figura 7. O método de desenvolvimento da arquitetura (ADM) do TOGAF
Como ilustrado pela Figura 7, o ADM do TOGAF compreende oito fases cíclicas após um período de “partida no motor”. Eu os acompanharei através dessas fases, na medida em que poderiam ser aplicadas ao estudo de caso da MedAMore. Mas, antes de a MedAmore poder iniciar o ADM, ela precisa ter alguma experiência com o TOGAF. A MedAMore terá duas opções para obter essa experiência.
Primeiramente, a MedAMore pode aprender sozinha a trabalhar com o TOGAF. A MedAMore pode fazer o download da documentação [20], que descreve tudo sobre o TOGAF, inclusive o ADM, detalhadamente. Pode comprar livros sobre o TOGAF [21]. Provavelmente há mais informações gratuitas e acessíveis sobre o TOGAF do que sobre todas as outras metodologias arquiteturais juntas.
Segundo, a MedAMore pode contratar consultoria em TOGAF. Existem consultores especializados em TOGAF, certificados pelo Open Group [22]. Como a MedAMore deseja minimizar quaisquer oportunidades de falha, escolheu chamar um consultor em TOGAF. A MedAMore contratou Teri, uma arquiteta certificada pelo Open Group em TOGAF. Lembre-se: os outros participantes da MedAMore são Cath, a CEO da MedAMore; Bret, o Vice-presidente comercial e Irma, a CIO.
Nesta fase preliminar, Teri participa de reuniões com os principais participantes da MedAMore para apresentar o processo do TOGAF. Suas três metas nesta fase preliminar são:
- Garantir que todos estejam satisfeitos com o processo;
- Modificar o processo do TOGAF, conforme necessário, para adaptá-lo à cultura da MedAMore;
- Definir o sistema de governança que supervisionará o futuro trabalho arquitetural na MedAMore.
Teri trabalhará em estreita colaboração com Bret para compreender a filosofia do negócio, seus modelos e os motivadores estratégicos da MedAMore. Ela também trabalhará em estreita colaboração com Irma para definir os princípios arquiteturais que orientam as arquiteturas tecnológicas da MedAMore e documentará esses princípios utilizando o formato recomendado pelo TOGAF.
Em algumas organizações, obter a adesão sobre a necessidade de uma arquitetura corporativa pode ser muito difícil. Esse fato é especialmente verdadeiro quando a iniciativa parte da organização de TI e ainda mais quando existe um histórico de discórdia entre as áreas comercial e técnica da organização. A MedAMore possui um histórico de animosidade. Entretanto, existe outro agravante para o qual Teri precisa considerar seriamente: a iniciativa não partiu da área de TI, mas da CEO Cath. Este fato dá grande visibilidade ao projeto e cria um incentivo positivo para a cooperação de todas as áreas.
Assim que Teri e a MedAMore concluírem a fase preliminar, estarão prontas para iniciar a Fase A que, pelo menos em teoria, começa com um Pedido de trabalho de arquitetura emitido por um dos departamentos da MedAMore. Este documento inclui os motivos do negócio para o pedido, informações sobre orçamento e pessoal e quaisquer limites a serem considerados. Como a MedAMore nunca emitiu um Pedido de trabalho de arquitetura, provavelmente a Teri precisará trabalhar com o departamento responsável para criar esse pedido.
Assim que o Pedido de trabalho de arquitetura (ou documento equivalente) for recebido, Teri (consultora TOGAF) dará início à Fase A do projeto MedAMore. Nessa fase, Teri tomará providências para que o projeto tenha o suporte necessário da MedAMore, definirá o escopo do projeto, identificará restrições, documentará as exigências do negócio e estabelecerá definições de alto nível para as arquiteturas básica (início) e final (desejada).
Estas definições, básica e final, incluirão definições de alto nível nas quatro subarquiteturas de EA apresentadas na Figura 5, ou seja, arquiteturas de negócio, tecnologia, dados e aplicativo.
O auge da Fase A ocorrerá com uma Exposição do trabalho de arquitetura, que deverá ser aprovada pelos vários participantes, antes do início da próxima fase do ADM. O resultado dessa fase é a criação de uma visão arquitetural da primeira passagem pelo ciclo ADM. A Teri orientará a MedAMore a escolher o projeto, validá-lo de acordo com os princípios de arquitetura estabelecidos na fase preliminar e garantir que os participantes adequados e seus problemas tenham sido identificados e considerados.
A visão arquitetural criada na Fase A será a principal informação da Fase B. A Teri tem como meta da Fase B criar arquiteturas detalhadas do negócio, básica e final, e executar uma análise completa das lacunas existentes entre elas. Para tanto, ela trabalhará, basicamente, com o Bret (ou com a equipe dele).
A Fase B é bastante complexa: envolve modelagem e análise altamente detalhada do negócio, além de documentação das exigências técnicas. Uma Fase B bem-sucedida exige informações de muitos participantes. Os resultados mais importantes serão uma descrição detalhada dos objetivos do negócio, básico e final, assim como as descrições das lacunas existentes na arquitetura do negócio.
A Fase C faz para a arquitetura dos sistemas de informação o que a Fase B faz para a arquitetura do negócio. Nesta fase, Teri trabalha principalmente com Irma (ou com a equipe dela). O TOGAF define nove etapas específicas, cada uma delas com várias subetapas:
- Criar a descrição da arquitetura básica de dados;
- Analisar e validar princípios, modelos de referência, pontos de vista e ferramentas;
- Produzir modelos de arquitetura, inclusive modelos de dados lógicos, de processos de gerenciamento de dados e de relacionamento que mapeiam as funções do negócio para operações de dados CRUD (Criar, Ler, Atualizar, Excluir);
- Selecionar blocos de construção da arquitetura de dados;
- Realizar revisões formais do ponto de controle do modelo de arquitetura e dos blocos de construção com os participantes;
- Revisar os critérios qualitativos (por exemplo, desempenho, confiabilidade, segurança, integridade);
- Completar a arquitetura de dados;
- Realizar análise de ponto de controle/impacto;
- Executar análise de lacunas.
O resultado mais importante desta fase serão as informações finais e a arquitetura de aplicativos.
A Fase D completa a arquitetura técnica: a infra-estrutura necessária para dar suporte à nova arquitetura proposta. A conclusão desta fase é realizada principalmente com a participação da equipe técnica da Irma.
A Fase E avalia as várias possibilidades de implementação, identifica os principais projetos de implementação que poderiam ser assumidos e avalia a oportunidade para o negócio associada a cada uma delas. O padrão TOGAF recomenda que o primeiro passo da Teri na Fase E seja “dar enfoque aos projetos que produzirão benefícios a curto prazo e, assim, criar uma força propulsora para dar andamento a projetos de prazo mais longo”.
Essa é uma boa recomendação para qualquer metodologia arquitetural. Assim sendo, Teri deverá procurar projetos que possam ser realizados da forma mais econômica possível e que, ao mesmo tempo, produzam o mais alto valor observado. Um bom lugar para se começar a procurar tais projetos são os problemas organizacionais que inicialmente convenceram Cath (a CEO da MedAMore) a adotar uma estratégia baseada na arquitetura corporativa. Esses problemas, anteriormente descritos, incluíam dificuldades para satisfazer as especializações regional e de depósito e a falta de confiabilidade para compartilhar dados.
A Fase F relaciona-se muito com a Fase E. Nesta fase, Teri trabalha com a equipe de governança da MedAMore para priorizar os projetos identificados na Fase E que incluem não apenas o custo e os benefícios (identificados na Fase E), mas também os fatores de risco.
Na Fase G, com base na lista de projetos ordenada por prioridade, Teri cria especificações arquiteturais para os projetos de implementação. Essas especificações incluirão os critérios de aceite e a listagem de riscos e problemas.
A fase final é a H. Nessa fase, Teri modifica o processo arquitetural de gerenciamento da mudança com quaisquer artefatos novos criados nesta última iteração e com novas informações que forem disponibilizadas.
Assim, Teri está pronta para reiniciar o ciclo. Uma das metas do primeiro ciclo deveria ser a transferência de informações para que os serviços da Teri fossem cada vez menos necessários à medida que mais e mais iterações do ciclo sejam concluídas.
Grande parte dos resultados do processo TOGAF será determinada igualmente pela relação Teri/MedAMore quanto pela própria especificação do TOGAF. O TOGAF tem como propósito ser extremamente adaptável e os detalhes para os vários artefatos arquiteturais são poucos. Um livro sobre o TOGAF afirma:
O TOGAF não é totalmente específico com relação aos documentos gerados; na verdade, oferece muito pouco na forma de modelos de documentos prescritivos: são meras orientações das entradas e saídas possíveis. [23]
A especificação do TOGAF é também flexível com relação às fases. Conforme expresso na própria especificação:
Uma das tarefas anteriores à aplicação do ADM é a revisão de seus componentes quando à aplicabilidade e, então, adaptá-los conforme adequado às circunstâncias da empresa específica. Esta atividade pode muito bem produzir um ADM “específico da empresa”. [24]
O TOGAF permite que as fases sejam realizadas de modo incompleto, ignoradas, combinadas, reordenadas ou remoduladas para se adaptarem às necessidades da situação. Assim, nada haveria de surpreendente se dois consultores, ambos com certificado TOGAF, acabassem utilizando dois processos muito diferentes, ainda que estivessem trabalhando com a mesma organização.
O TOGAF é ainda mais flexível sobre a arquitetura real gerada. De modo surpreendente, o TOGAF na verdade não é partidário de nenhuma arquitetura. A arquitetura final pode ser boa, ruim ou inócua. O TOGAF apenas descreve como gerar uma arquitetura corporativa, não necessariamente como gerar uma boa arquitetura corporativa. Por isso, depende-se da experiência da equipe e/ou do consultor TOGAF. As pessoas que adotam o TOGAF na esperança de conseguir uma solução mágica ficarão muito desapontadas (assim como com qualquer das metodologias).
