É atribuição do arquiteto, como orquestrador, estabelecer a “conexão” entre as partes – aqueles que têm acesso às informações e os que têm poder decisão, tanto no sentido da estratégia para a operação, quanto da operação para a estratégia. Para isso, é essencial explicitar as “motivações” das partes, afinal, elas são mais significativas no estabelecimento de relacionamentos do que regras e procedimentos.
Explicitando “interessados” e aspectos de interesse
Esforços de arquitetura corporativa precisam evidenciar stakeholders e drivers como forma de melhorar a comunicação e a obtenção do patrocínio executivo “certo”.
Eventualmente, esforços de modelagem de interessados e aspecto de interesse podem levar a produção de visões como a indicada acima, que se destacam por algumas obviedades – CFO interessado em lucratividade (desdobrada em receitas e estrutura de custos), CMO focado no marketshare e o CEO combinando as duas visões. Entretanto, é sempre bom lembrar que “bom senso não é senso comum”. Mesmo visões óbvias, compondo o repositório da arquitetura, serão importantes para no estabelecimento de planos de comunicação mais eficientes.
Explicitar os aspectos de interesse evita que se dê ênfase exagerada a determinadas características de projetos para determinados interlocutores, reduzindo eventuais “ruídos” que só atrapalham a comunicação.
Visões, modelo e o repositório arquitetural
A arquitetura corporativa pode ser “explicitada” de diversas formas, mas, uma das mais interessantes é utilizando alguma notação ou linguagem gráfica como a Archimate. O resultado desse esforço de explicitação é o modelo, ou seja, um conjunto de simplificações da realidade AS-IS e TO-BE, contemplando sobretudo elementos e relações.
O modelo de uma arquitetura corporativa fica expresso em um conjunto visões. Uma visão, geralmente expressa em um diagrama, apresenta um “recorte” do modelo com intenção em colocar evidência em algum aspecto relevante.
O conjunto de todas as visões produzidas representa o que uma organização conseguiu explicitar do modelo. Idealmente, todas as visões são armazenadas de forma organizada constituindo o repositório da arquitetura.
Boas ferramentas de software permitem inferências e análises do modelo através das visões mantidas no repositório.
Explicitando “conhecimento prévio” importante
 | Precisamos compreender que o desenvolvimento de uma organização é um processo educacional de acumulação de conhecimento. Vicente Falconi |
Empresas aprendem analisando seus próprios resultados e processos, bem como o que é evidente em seus contextos de atuação. Parte do esforço de arquitetura corporativa deve ser vincular esses “conhecimentos prévios” com os aspectos de interesse dos diversos stakeholders.
Relacionando “objetivos” e outcomes
Alterações na arquitetura corporativa buscam sempre modificar o ambiente operacional – e a gestão da rotina – para promoção de melhorias de médio e longo prazo.
É extremamente relevante, para a assertividade, que fiquem explicitadas as relações entre metas e objetivos da organização com aspectos de interesse das diversas partes.
No diagrama acima, por exemplo, fica evidente a preocupação do CIO com a disponibilidade dos serviços digitais da companhia e a vinculação natural deste aspecto de interesse com arquiteturas baseadas em nuvem, daí, o estabelecimento da meta de migrar 100% dos serviços para a nuvem. Entretanto, é importante que um potencial “empecilho” para esta iniciativa é o “conhecimento prévio” de que os custos com nuvem podem ser mais elevados do que de infraestrutura on-premises, o que coloca o CFO como opositor natural a esta iniciativa.
Conhecimentos imprecisos, decisões ruins
Muitas decisões ruins são consequência de “conhecimentos prévios” imprecisos. A ideia, por exemplo, de que os “custos da nuvem” são mais altos do que em infraestruturas on-premises é verdadeira para alguns cenários, mas não para todos.
A explicitação dos “conhecimentos prévios” relacionados a aspectos de interesse dos stakeholders ajuda a entender diretrizes e requisitos sem sentido, tão comuns, principalmente em empresas maiores.
Já no diagrama acima, fica evidente que e-commerce é um aspecto de interesse importante para o CMO e que pode contribuir para o “alívio” da estrutura de custos que é importante para o CEO e, também, para o CFO (não explícito nessa visão, mas fácil de observar no repositório da arquitetura).
Já na visão expressa no diagrama acima, fica indicado que disponibilidade é algo importante para o sucesso do e-commerce, pois impactam, entre outras coisas, na lucratividade. Disto, desdobra-se um potencial argumento em defesa de investimentos maiores na nuvem, mesmo com o impacto negativo na estrutura de custos.
Explicitando “diretrizes” ou princípios
Explicitados interessados, aspectos de interesse, conhecimentos prévios, objetivos e metas, fica mais natural o estabelecimento fundamento de diretrizes organizacionais.
Na visão expressa no diagrama acima, por exemplo, fica explícito o “acordo” entre CIO e CFO de observar para todos os projetos o princípio de que “a conte fecha” quando os custos eventuais provenientes da nuvem são “tolerados” de que exista compensação suficiente para a lucratividade.
Derivando “requisitos” de diretrizes
Enquanto diretrizes são “globais” para a organização, requisitos são especializações das diretrizes da organização para iniciativas específicos.
Na visão expressa no diagrama acima, fica explícito um desdobramento do princípio de “todo custo com nuvem precisa ser justificado com aumento na lucratividade” em um requisito para o objetivo de “consolidar” o e-commerce.
Explicitando “restrições”
Eventualmente, além de requisitos convencionais, derivados de aspectos de interesse dos stakeholders e “conhecimentos prévios”, há também restrições contextuais (geralmente oriundos de acordos e normas) ou restrições ou auto-impostas.
A visão expressa no diagrama acima, por exemplo, relaciona governança como aspecto de interesse do CEO e, em decorrência disso, o objetivo de estar em conformidade com a lei de proteção de dados européia. Daí o desdobramento de metas para estabelecimento, adoção e verificação de práticas de governança de dados e dois princípios derivados.
Na visão expressa no diagrama acima, fica expressa então uma restrição, derivada da política de governança da companhia, quanto a certificações que demonstrem adequação a práticas de governança conformes as políticas da organização.
Para pensar…
Todas as decisões de arquitetura são relacionadas a design (componentes, responsabilidades e relacionamentos). Entretanto, nem todas as decisões de design são arquiteturais.
Quanto mais implícitas as “motivações” maiores as chances de ruído de comunicação que retardam as tomadas de decisão. Maiores as chances de que decisões sejam tomadas sem informações apropriadas e que conhecedores da informação sejam ignorados nos processos decisórios, gerando prejuízos para todos.
// TODO
Antes de avançar para o próximo capítulo, recomendo as seguintes reflexões:
- Quanto explícitos estão os stakeholders e drivers em sua organização?
- Como requisitos e restrições para projetos são vinculados a objetivos estratégicos?
- Será possível construir documentação abrangente sobre as “motivações” de uma organização sem alguém responsável por fazer esse mapeamento?
