sexta-feira, 31 de julho de 2015

Como Arquitetura Corporativa pode apoiar a implantação de Transparência Organizacional A Arquitetura TOGAF no apoio a implantação de Transparência – Fase A

No artigo passado eu comecei uma discussão sobre como o framework de arquitetura TOGAF pode apoiar a implantação de transparência e falei da primeira fase: a Preliminar.


Hoje eu vou falar sobre a fase A. Visão da Arquitetura.





A segunda pergunta é: O que vamos fazer? Por quê? Com quem? Quando? Onde? Todo mundo está de acordo? 



Há uma série de questões que precisam ser resolvidas como: O escopo do trabalho (quais informações, órgãos, objetivo estratégicos, etc estão envolvidos); as restrições ao projeto; expectativas de todos os envolvidos; metas; organização e divisão do trabalho; riscos ao projeto; projetos diretamente ligados que já estão em andamento;

Essa fase inicia uma iteração do ciclo de desenvolvimento da arquitetura. Repetindo-me: Não vamos fazer arquitetura da organização inteira de uma vez só. Ela é feita por partes e, portanto, a cada “rodada” da arquitetura (será que é por isso que o Open Group representa o TOGAF como uma roda?) é definido um plano do projeto que será realizado naquela iteração.

Da mesma forma, a estratégia de implantação de transparência significa que, assim como com o TOGAF, não é possível implantar transparência em tudo de uma só vez. É necessário definir um escopo fechado e na próxima rodada de arquitetura definir outro escopo e assim por diante. Esse escopo deve estar em consonância com o escopo da arquitetura corporativa que está sendo definido neste momento. Envolve definir quais serviços, ou informações, ou áreas da empresa vão ser abrangidas naquele momento e em que extensão.

O Open Group apresenta uma figura que ilustra bem essa questão do particionamento da Arquitetura. Existem dois eixos importantes que devem ser considerados ao longo de um período de tempo: 

  • Primeiro o eixo do nível (Level): Nele o grupo de Arquitetura define a abrangência da iteração. São definidos os segmentos, processos, serviços, órgãos, áreas, conjunto de informações e outras partes da empresa que serão trabalhados na rodada.
  • O segundo eixo é a profundidade ou extensão (Breadth): Nele o grupo de Arquitetura define o nível de detalhe de cada tipo de informação e quais domínios de arquitetura serão atendidos (Negócio, Dados, Aplicativos, Tecnologia).



Exemplo: Na iniciativa de modelagem de processos, o Escritório de Processos, junto com o Arquiteto vai definir que neste momento, para a área da empresa que vai fazer parte da rodada serão modelados os processos X, Y e Z (level) para uma determinada área da organização e serão modeladas somente determinadas informações (breadth) como fluxo de atividades, entradas, saídas, sistemas utilizados e riscos associados. 

É assim também com transparência: Na fase A, dentro do escopo que está sendo definido, deve-se identificar que aspectos de transparência são importantes para definir quais informações são necessárias representar nos modelos arquiteturais.

O Modelo de Maturidade em Transparência Organizacional ajuda na identificação dos requisitos de dados que os modelos arquiteturais devem conter para que as suas operacionalizações sejam realizadas através de ações, sistemas, metodologias, etc.

Seguindo o exemplo anterior da modelagem de processos, o grupo de Arquitetura pode identificar as seguintes características de transparência importantes de serem operacionalizadas: Publicidades, Portabilidade, Clareza e Rastreabilidade.


  • Publicidade: Será necessário estabelecer o grau de sigilo das informações para que depois os sistemas, processos de solicitação de informação (SIC ?), etc sejam capazes de, adequadamente, disponibilizar as informações respeitando as leis de sigilo. Então para cada informação ou documento manipulado nos processos X, Y e Z é necessário que o modelos arquiteturais registrem o grau de sigilo da informação. É necessário também: existir um modelo que define os graus de sigilo de informação existentes e os tipos de locais (web, telefone, impressa, etc) onde cada informação pode ser veiculada (se houver alguma regra). Os processos e informações podem também ter graus de sigilo diferentes de acordo com o tipo de solicitante.

  • Portabilidade: Uma das ações necessárias diz respeito a permitir o acesso às informações em diferentes formatos (sendo pelo menos um aberto). Então para cada informação é necessário associar a ela os formatos em que será disponibilizada.
  • Clareza: Uma das ações necessárias está relacionada a definir normais de apresentação da informação que sejam adequadas a cada público que a irá consumir. Então é necessário levar isso em consideração quando se for pensar nos modelos arquiteturais e em como as informações serão escritas, representas e relacionadas entre si. Pode, inclusive, ser necessário representar a informação de mais uma forma. Pense em informações de cunho jurídico: Dependendo do público que as irá consumir, será necessário representar as mesmas em formatos distintos para se torne claro e todos possam entender. Se na rodada de arquitetura o escopo do projeto envolve trabalhar com este tipo de processo e informação, para implantar transparência é necessário pensar nessa característica.
  • Rastreabilidade: Uma ação importante é identificar a fonte e o responsável pelas informações e processos. Se no escopo da rodada de arquitetura está previsto modelar os processos X, Y e Z então é necessário somente verificar se na modelagem, os responsáveis pelas atividades e gestores dos processos estão previstos na modelagem. Se já estiver, você já está fazendo transparência! Check! 

No próximo artigo vou falar sobre as fases B, C e B que envolvem desenvolver os modelos arquiteturais baseado no escopo, premissas, restrições e acordos realizados na fase A. 


Um comentário :

  1. Acho que o PEN (Processo Eletrônico Nacional) poderia ser o veículo para se implantar um ESB de entidades ao estilo DAMABok (person). O PEN já pretende unificar protocolos entre o SIAPE, SICAF, SIORG, etc., e seria o veículo ideal para tal. Já trabalhei na implantação de arquitetura parecida em Ingres em 95 na Centrus (pessoa), que vigora até hoje, e em SQL Server. Seria a solução, aproveitando-se da implantação do SEI em vários órgãos da APF para padronização das entidades do governo brasileiro, evitando-se redundância e inconsistências.

    ResponderExcluir