Comunicando Arquiteturas Corporativas (Parte 2)

Por Antonio Plais (*)

Na nossa postagem anterior  abordamos a importância da arquitetura corporativa para a transmissão do conhecimento sobre a estrutura e o funcionamento das organizações, e para a efetiva melhoria dos seus serviços para a Sociedade. Mostramos como os usos potenciais das descrições da arquitetura envolvem a comunicação, nas suas mais diversas formas: textual, verbal, visual, ou qualquer combinação delas. Nesta postagem, discutiremos o desenvolvimento de sistemas como um processo de transformação do conhecimento.

O desenvolvimento de sistemas como um processo de transformação do conhecimento

O processo de desenvolvimento de sistemas pode ser considerado um processo de transformação do conhecimento, onde conversações são usadas para compartilhar e criar o conhecimento necessário tanto ao sistema sendo construído, como ao próprio processo de desenvolvimento. O termo ‘conversação’, neste contexto, deve ser interpretado no sentido amplo, ou seja, desde uma elicitação um-a-um como uma oficina reunindo diversas partes interessadas, através de qualquer meio de comunicação.

Comunidade de desenvolvimento de sistema

Se o nosso foco está no processo de comunicação, é importante identificar os atores que desempenham um papel na comunicação que ocorre durante o desenvolvimento do sistema. Estes atores provavelmente têm algum interesse em relação ao sistema sendo desenvolvido, como por exemplo, responsáveis pelo problema, futuros usuários do sistema, especialistas de domínio, patrocinadores, arquitetos, engenheiros, analistas de negócio, etc.

No entanto, estes atores não são os únicos ‘objetos’ que desempenham um papel importante no desenvolvimento do sistema. Documentos, modelos, formulários, regulamentos, etc., que representam partes do conhecimento pertinentes ao sistema em desenvolvimento, também são uma classe importante de objetos a serem considerados. O conjunto completo de objetos (atores e conhecimento) que desempenham um papel no desenvolvimento do sistema formam a comunidade de desenvolvimento de sistema.

Os atores em uma comunidade de desenvolvimento de sistema possuem algum interesse específico em relação ao sistema em desenvolvimento. Este interesse implica em interesses relacionados com as (o conteúdo das) descrições do sistema que são comunicadas dentro da comunidade. Estes interesses são definidos pelo padrão ISO/IEC/IEEE42010:2011 como as preocupações das partes interessadas.

Preocupação: um interesse de uma parte interessada em relação à descrição da arquitetura de algum sistema, resultado das metas das partes interessadas, e pelo(s) papel(éis) presente(s) ou futuro(s) desempenhados pelo sistema em relação a estas metas.

Alguns exemplos de preocupações são:

• A situação atual em relação ao apoio de um sistema computadorizado a um processo de negócio
• Os requisitos de uma parte interessada em relação a uma situação desejada
• As melhorias que o novo sistema em desenvolvimento pode trazer, em relação ao custo de aquisição de um sistema padronizado de prateleira
• O impacto potencial do novo sistema nas atividades dos seus futuros usuários

Conhecimento do desenvolvimento de sistema

A comunicação que acontece dentro de uma comunidade de sistema tem como objetivos essenciais a criação, desenvolvimento e disseminação do conhecimento sobre o sistema que está sendo desenvolvido. Dependendo das suas preocupações, as partes interessadas estarão interessadas em diferentes tópicos deste conhecimento. Mas que tipo de conhecimento é relevante para o desenvolvimento de um sistema ou, em outras palavras, que tópicos de desenvolvimento podem ser distinguidos?

Entre os diferentes tópicos que podem ser criados e compartilhados entre os membros da comunidade de desenvolvimento, podemos distinguir entre o domínio alvo pertencente ao sistema em desenvolvimento, e ao domínio do projeto, do processo, de desenvolvimento em si. Estes dois grandes domínios de conhecimento podem ser refinados em tópicos mais específicos, de acordo com algumas caracterizações:

• Perspectivas: os artefatos que compõem a descrição do conhecimento podem ser considerados a partir de diferentes perspectivas:
• Os aspectos de negócio, aplicativos e tecnologia de um sistema de informações (computadorizado)
• Os aspectos social, simbólico e físico de um sistema
• Os processos, informações, lógica, atores e tecnologia incorporados em um sistema

A ideia das perspectivas sobre um sistema nos remete ao conceito de ‘ponto de vista’, que é definido como sendo ‘um ponto de vista a partir do qual uma perspectiva de um sistema é descrita’. A definição de um ponto de vista inclui não somente a definição da perspectiva que ele toma em relação ao sistema, mas também a linguagem que será usada para descrever o sistema, bem como orientações sobre a sua construção e interpretação. Em contraste, uma perspectiva é puramente “conceitual”.

• Escopo: Dado um domínio, podemos identificar diversos escopos para a abordagem do problema: corporativo, departamental, do projeto, ou mesmo de uma atividade específica.

• Cadeia de desenho: Ao considerar o desenho de um artefato, podemos distinguir algumas características:

• Propósito: para que propósito o artefato é necessário
• Funcionalidade: que funcionalidade o artefato deve prover para seu ambiente
• Desenho: como esta funcionalidade deve ser realizada
• Qualidade: quão bem ele deve fazer isso
• Custo: a que custo ele deve fazer isso e qual o custo para o seu desenvolvimento

• Perspectiva histórica: Dado um artefato como um desenho, podemos distinguir as suas diferentes versões que este desenho pode apresentar ao longo do tempo: a versão corrente que está em uso, uma versão futura que orienta o desenvolvimento do sistema, (o rascunho de) uma versão futura posterior ao desenvolvimento em curso (e que serve como guia para o seu desenvolvimento no longo prazo), e quaisquer outras versões intermediárias. Podemos considerar ainda, no âmbito do próprio processo de desenvolvimento, o planejamento/estratégia de execução que está sendo adotado, e o planejamento/estratégia que estava em uso no passado.

• Nível de abstração: Quando considerando um domínio, diversos níveis de abstração podem ser utilizados, como, por exemplo, tipo-instância, generalização/especialização, encapsulamento, ocultação de detalhes de implementação etc.

Como mencionado anteriormente, as diferentes partes interessadas podem, dependendo de suas preocupações, estar interessadas em diferentes tópicos do conhecimento. Por exemplo, um executivo financeiro pode estar interessado em uma perspectiva de investimentos, no nível corporativo geral, de um sistema, enquanto um desenhista pode estar interessado em todos os aspectos e detalhes da cadeia de desenho das diversas perspectivas.

Explicitação do conhecimento

Os atores em uma comunidade de desenvolvimento de sistemas precisam comunicar o conhecimento sobre o sistema entre si. No campo do gerenciamento do conhecimento, uma distinção é feita entre o conhecimento tácito e o conhecimento explícito. Este último se refere àquele conhecimento que pode ser representado de alguma forma, e a explicitação do conhecimento sobre o sistema é o processo de codificá-lo (representá-lo) através de algum meio e linguagem, por exemplo, de modelos de arquitetura. O conhecimento tácito, por outro lado, não pode ser facilmente representado através de algum meio, e não é o foco desta discussão.

Descrições da arquitetura (de sistemas) são formas de conhecimento explícito sobre um sistema existente ou futuro: seu desenho, seu processo de desenvolvimento, as considerações subjacentes etc. Considerando este foco, a explicitação do conhecimento pode ser avaliada de acordo com algumas dimensões:

• Formalidade: indica o tipo de linguagem e o quanto ela é formal (ou seja, sujeita a rígidas regras de semântica) ou informal (como a linguagem natural ou diagramas livres).
• Quantificabilidade: Diferentes aspectos do artefato sendo desenhado podem ser quantificados através de medidas como, por exemplo, volume, capacidade, carga de trabalho, esforço, recursos, uso, tempo, duração, frequência, etc.
• Executabilidade: O conhecimento representado pode (quando relativo a artefatos com comportamento operacionais) ser tão explícito que permita sua execução. Esta execução pode tomar a forma de uma simulação, protótipo, animações geradas, ou operação real.
• Compreensibilidade: A representação do conhecimento deve ser compreensível pela audiência pretendida. Ajustar o nível de compreensibilidade requerido para a representação, em particular a linguagem utilizada, é crucial para o sucesso da comunicação.
• Completude: A representação do conhecimento pode ser completa, incompleta, ou sobrecompleta em relação ao tópico de conhecimento que ela pretende cobrir.

Transformação do conhecimento

Durante o desenvolvimento do sistema, o conhecimento sobre ele e sobre o seu desenvolvimento evolui. Novas percepções emergem, desenhos são criados, visões são compartilhadas, opiniões são formadas, decisões de desenho são feitas, etc. O conhecimento que está presente na comunidade de desenvolvimento pode ser visto como evoluindo através de vários estados. Ele deve ser, inicialmente, introduzido na comunidade e, em seguida, compartilhado com os membros da comunidade. Este compartilhamento leva a mudanças no “estado do conhecimento” dos atores da comunidade de desenvolvimento, que progridem através dos estágios descritos abaixo:

• Consciente: Um ator pode se tornar consciente do conhecimento (possível) através do compartilhamento de outro ator.
• Acordado: Uma vez que o conhecimento é compartilhado, um ator pode fazer sua própria avaliação e decidir concordar ou não com o conhecimento compartilhado.
• Compromissado: Atores que concordam com um tópico de conhecimento específico podem decidir efetivamente se comprometer com ele. Em outras palavras, eles podem decidir moldar seu comportamento futuro de acordo com este conhecimento.

Não existe uma forma de determinar objetivamente o nível de consciência, concordância ou compromisso de um dado ator ou conjunto de atores com um certo tópico de conhecimento. É uma questão de avaliação, e esta avaliação será feita por (alguns) atores da comunidade de desenvolvimento, e comunicada e discutida de forma aberta e transparente por toda comunidade, de forma a ensejar o entendimento e compromisso de (possivelmente) todos os seus membros.

Próximos passos

Na continuação desta série de artigos, vamos discutir:

• Estratégias de conversação (para a comunicação em geral)
• Conversações para a comunicação da arquitetura
• A linguagem ArchiMate como meio de descrição de arquiteturas

Até a próxima!!

(*) Baseado no livro Enterprise Architecture at Work, 4ª edição (2017), Marc Lankhorst et al