Como representar e aplicação e banco de dados no metamodelo completo TOGAF?

5

Eu quero capturar a conexão entre um aplicativo e o banco de dados de maneira consistente com o relacionamento entre as entidades, conforme definido no modelo de meta do conteúdo.

  • Estamos usando o metamodelo completo ref 34-8 i beleive minha pergunta está relacionada à extensão de dados e à extensão de consolidação da infraestrutura.
  • Isso está sendo capturado em uma ferramenta de modelagem (útil para análise posterior de impacto)
  • O ponto de vista é destinado a um público técnico que precisa entender quais aplicativos e bancos de dados serão atualizados. Nesse ambiente, na maioria dos casos, o aplicativo para banco de dados é um para um

Abaixodescrevearelaçãoqueeuqueroexibir

Qual é uma boa maneira de descrever essa relação que é consistente com o meta-modelo e ajudará o público a entender o que eles precisam mudar? Quais são os fatores que irão alterar a melhor maneira de descrevê-lo.

    
por user1605665 04.08.2017 / 03:39
fonte

3 respostas

3

Embora as respostas acima sejam ponderadas, elas não respondem ao que é uma pergunta muito direta, que é a entidade no metamodelo TOGAF que seria usada para representar um banco de dados.

A resposta, muito simplesmente, é se for um banco de dados físico (ou seja, você está criando um modelo de arquitetura física) e, em seguida, você usaria o Componente de Dados Físicos; se for um banco de dados lógico (ou seja, você está criando um modelo de arquitetura lógica), você usaria um componente de dados lógicos.

    
por 17.04.2018 / 00:44
fonte
2

Não existe um modelo mágico para o TOGAF - O TOGAF é uma metodologia para descrever arquiteturas existentes, futuros estados de arquitetura e os roteiros para ir de um para outro. Essa pergunta faz tanto sentido para o indivíduo certificado do TOGAF quanto a pergunta "Como representar e aplicar e banco de dados no PRINCE2" para um indivíduo qualificado pelo PRINCE2.

Use a representação mais apropriada que funciona para o seu público . O TOGAF defende a existência de uma série de "pontos de vista" da arquitetura, visando diferentes preocupações dos grupos de partes interessadas e diferentes níveis de detalhes. Decida quais pontos de vista você precisa criar e certifique-se de que cada ponto de vista tenha um diagrama claro que informe às partes interessadas o que elas precisam saber.

No exemplo acima, você gostaria de incluir ou ocultar detalhes técnicos para determinados públicos, mas ambos os diagramas seriam apropriados para um nível de detalhe, portanto, não se preocupe com a cor ou a forma das caixas, desde que as informações sejam é acessível e compreensível.

Edite após as alterações na pergunta

Quando eu fiz um curso TOGAF antes dos meus exames de certificação, o treinador explicou que os Modelos fornecidos com os materiais do TOGAF eram um compromisso entre todos os participantes (Veja a lista de membros das páginas xxv - xxx na edição 9.1 do o livro e imagine fazer com que todos concordem em qualquer coisa - CA, CSC, HP, IBM ...) e, como tal, eram praticamente inúteis.

Ele forneceu exemplos do mundo real (com nomes redigidos, mas de outra forma completos) da garantia produzida por sua empresa, no entendimento de que nós, estudantes, não poderíamos tirar cópias, mas poderíamos olhar. Esta foi uma experiência libertadora, pois nos libertou dos extremamente limitados "Modelos" fornecidos no próprio TOGAF e nos mostrou como criar materiais de alta qualidade usando nada mais sofisticado do que o Visio.

Então, o que eu estou dizendo é - olhe para os exemplos dados, mas NÃO os use religiosamente, pois eles estão muito comprometidos para nada mais do que um guia. Estou olhando para o TRM (Capítulo 43) pela primeira vez desde que passei nos exames (o que deve ser uma pista) e é ainda mais inútil do que eu me lembrei :). Edições anteriores do "Journal of Enterprise Architecture" (disponível para membros) geralmente incluem exemplos e geralmente são melhores do que qualquer coisa oferecida oficialmente pelo The Open Group.

Construa sua própria arquitetura com base no que você precisa documentar e explicar para as partes interessadas. Um público técnico esperará um modelo de dados completo, um usuário de negócios técnico pode querer um modelo de dados conceitual, executivos de nível C ficarão felizes com uma caixa que representa o banco de dados. Use cores para indicar áreas que requerem atenção.

    
por 04.08.2017 / 07:44
fonte
1

Com base na sua descrição de querer capturar as conexões entre um aplicativo e um banco de dados, eu concordaria que tanto as Extensões de Dados (definidas no Capítulo 34.4.4) quanto as Extensões de Consolidação de Infraestrutura (definidas no Capítulo 34.4.5) são apropriadas . Especificamente, dois dos propósitos das Extensões de Dados são capturar a "criação de componentes de dados físicos que implementam componentes de dados lógicos e são análogos a bancos de dados, registros, repositórios, esquemas e outras técnicas de segmentação de dados" e a "criação de dados ciclo de vida, segurança de dados e diagramas de migração de dados da arquitetura para mostrar as preocupações de dados em mais detalhes ". Algumas das finalidades das Extensões de Consolidação de Infraestrutura são capturar "a criação de componentes de aplicativos lógicos e físicos para abstrair a capacidade de um aplicativo longe dos aplicativos existentes" e "a criação de componentes de aplicativos lógicos e físicos para abstrair o tipo de produto". produtos de tecnologia real existentes ".

Se você fosse criar totalmente essas duas extensões, seria necessário criar os seguintes diagramas:

  • Diagrama de segurança de dados
  • Diagrama de migração de dados
  • Diagrama do ciclo de vida de dados
  • Diagrama de realização de processos / aplicativos
  • diagrama de engenharia de software
  • Diagrama de migração de aplicativos
  • diagrama de distribuição de software
  • Processando diagrama
  • Diagrama de computação em rede / hardware
  • Diagrama de engenharia de comunicações

Todos esses diagramas são definidos em Artefatos arquitetônicos (Capítulo 35) .

Com base no desenho da sua pergunta, o Diagrama de Distribuição de Software e o Diagrama de Computação em Rede / Hardware correspondem mais de perto a isso. O diagrama do Software Distribution mostra a estrutura do aplicativo e a distribuição física em partes físicas de tecnologia e localização geográfica. O diagrama de Computação em Rede / Hardware mostra as conexões lógicas entre os componentes do aplicativo. Como você também menciona atualizações para aplicativos e bancos de dados (estou interpretando que para ser uma implantação de uma nova versão ou uma atualização de tecnologia para um novo fornecedor), o Application Migration Diagram parece apropriado e mostra como você pretende mudar de as versões de linha de base dos componentes para a versão de destino em todos os ambientes. Deve-se notar que todos eles se enquadram nas extensões de consolidação de infra-estrutura.

Examinando as definições completas desses diagramas (e examinando as definições dos outros diagramas), o TOGAF nunca especifica uma notação ou técnica de modelagem específica. Cada uma das extensões do TOGAF descreve uma faceta particular da arquitetura, um conjunto de modelos que ajudam a capturar informações relevantes para essa faceta da arquitetura e fornece nomes específicos para diagramas que atendem a propósitos específicos.

Se você precisa seguir os padrões do TOGAF, a melhor coisa a fazer seria escolher suas extensões (parece que você tem), garantir que a finalidade esteja alinhada com o que você está tentando comunicar, veja os diagramas de lista que suportam essa extensão, observe a intenção e o propósito desses diagramas. Em seguida, trabalhe com as partes interessadas que usarão a documentação (não são apenas os diagramas - é provável que haja texto, tabelas e outras informações) associados a essa extensão.

Outra recomendação é o Padrão IEEE para Tecnologia da Informação - Design de Sistemas - Descrições de Design de Software (1016) : o uso de linguagens de design padronizadas é preferível a outras linguagens de design. A ideia se você está usando uma linguagem de design padronizada (e usá-la corretamente), então você não precisa explicar o que sua notação significa para os leitores. Se você não estiver usando uma linguagem de design padronizada ou usando símbolos de uma linguagem de design padronizada de maneira não padronizada, precisará de conteúdo adicional para explicar aos leitores como interpretar seus diagramas e notações de design, o que leva a uma arquitetura ou design mais detalhado descrição.

Em suma: primeiro, consulte suas partes interessadas. Descubra quais diagramas e modelos seriam mais fáceis de entender e usar. Pode haver padrões organizacionais ou convenções já em vigor. Se não houver padrão, convenção, preferência ou consenso, procure uma notação padronizada que possa ser usada para comunicar as informações que o diagrama deve comunicar. Se não houver uma notação padronizada, você poderá optar por usar uma anotação criada por você mesmo, desde que também deixe claro para o leitor como entender essa notação.

    
por 08.08.2017 / 12:28
fonte