O que é Arquitetura de Aplicativos?
Quatro elementos da arquitetura de aplicação
Tipos de modelos de arquitetura de aplicação
- Navegar pelos tipos de modelos
- Modelo de Sistema de Informação
- Modelo de Aplicação Lógica
- Modelo de Serviço de Informação Lógica
- Modelo de Integração Lógica
O que é Arquitetura de Aplicativos?
A arquitetura de dados explica e permite a necessidades de dados da empresa. É descrito através de quatro elementos—necessidades de dados, principais fontes de dados, principais tipos de dados, e o necessário recursos de gerenciamento de dados.
Nós usamos quatro modelos de arquitetura corporativa para descrever sua arquitetura de dados - a modelo de assunto, modelo de área temática, modelo lógico de dados, e modelo de documento lógico.
A arquitetura de aplicação tem o seguinte papel em arquitetura de sistemas de informação. Segue-se arquitetura de dados. Arquitetura de Sistemas de Informação é uma especialidade domínio de arquitetura que alinha funcionalidade, fluxo de dados, e gerenciamento de dados. Na prática, isso significa garantir que os aplicativos estejam fornecendo o fluxo de dados e o gerenciamento de dados necessários, não apenas fornecendo recursos.
Vamos nos concentrar nesta afirmação por um momento. Os aplicativos existem para processar e gerenciar dados. Sem uma sólida compreensão e design da Arquitetura de Dados, os aplicativos se tornam ilhas desconectadas. À medida que entregam recursos, geram dívida técnica. Eles criam complexidade no fluxo e no gerenciamento de dados. Fluxos e gerenciamentos de dados complexos aceleram sua dívida técnica e adicionam complexidade à governança de dados.
Isso significa que seu arquitetura de aplicativos está focado no estrutura e interação dos aplicativos que fornecem a funcionalidade necessária e o gerenciamento de dados, você tem uma arquitetura de sistemas de informação.
Sem sucesso transformação digital serão construídos com base na funcionalidade. Eles são sempre construídos com base em dados.
Quatro elementos da arquitetura de aplicação
Cada arquitetura de aplicação abordará:
Por si só, esses elementos nos ajudam a entender a estrutura de nossos aplicativos: o que eles fazem, como devem ser montados e como as partes interagem.
Nossos aplicativos existem para gerenciar dados e fornecer funcionalidade.
Estamos buscando como agrupar e montar a funcionalidade e o gerenciamento de dados necessários. A montagem é o desafio crítico da arquitetura do aplicativo.
Tenha em mente que a funcionalidade pode ser colocada em qualquer lugar: incorporada em um aplicativo corporativo, exposta por um microsserviço ou integrada a um ASIC. A montagem define os limites de integração, o ciclo de vida e a dependência.
Sabemos que a arquitetura de aplicações permite grandes arquitetura empresarial. Você deve conhecer funcionalidade, fluxo de dados e gerenciamento de dados. O fluxo de dados determina como a arquitetura do aplicativo e a arquitetura de dados permitem que você arquitetura de negócios.
Funcionalidade
A arquitetura do aplicativo começa com a funcionalidade.
A funcionalidade se divide em quatro grupos:
- Funcionalidade necessário para fazer o trabalho: Quando os aplicativos executam a tarefa. Esta é a funcionalidade mais interessante em um sistema automatizado.
- Funcionalidade necessário para registrar o trabalho: Quando outra coisa executa a tarefa, e a funcionalidade simplesmente registra os dados criados ou que o trabalho foi realizado. A maioria das funcionalidades de software se enquadra nesse grupo: registra informações para pessoas ou outros sistemas automatizados.
- Funcionalidade necessário para gerenciar o trabalho: Agendamento, gerenciamento de tarefas, coordenação e acompanhamento de todas as atividades. Isso é necessário para uma atividade empresarial bem gerenciada e de alta eficiência. Muitas vezes, isso é esquecido quando falamos sobre o trabalho.
- Funcionalidade necessária necessário para gerenciar os dados: Armazenar, recuperar, misturar, avaliar, mover e proteger os dados.
Você precisa ter um conjunto consistente de funcionalidades. Na maioria dos nossos modelos, distinguimos gravação e execução como atributos.
Quando negligenciamos a funcionalidade de gerenciamento — seja do trabalho ou dos dados — diminuímos o valor dos nossos sistemas.
A funcionalidade está diretamente ligada à Modelo de Função Lógica.
Conjunto
Considerar a melhor forma de montar a funcionalidade é a tarefa mais importante para um arquiteto de aplicativos.
A montagem é onde você cria ou minimiza a complexidade da integração e do fluxo de dados. É onde você obtém reutilização, especialização e atende a requisitos operacionais exclusivos.
A montagem não é feita a partir da perspectiva de um melhor teórico. Isso é feito levando em consideração a dura realidade e os requisitos operacionais. Considere as vantagens de desempenho e potência de ASICS personalizados. Ou as implicações de desempenho e dados, independentemente de a função ocorrer em um dispositivo móvel ou no data center. Ou os desafios de integração ao equilibrar vários sistemas comerciais e um complemento personalizado.
A Assembleia está diretamente ligada à Modelo de Serviços Lógicos.
Interação
Como as diferentes partes do seu portfólio de aplicativos irão interagir.
Decisões simples sobre usar um Message Bus, uma API ou um banco de dados compartilhado são escolhas diretamente ligadas à agilidade do aplicativo, à sustentabilidade e ao gerenciamento da dívida técnica.
Arquitetos de aplicativos experientes entendem por que a funcionalidade é montada e os métodos de interação entre os diferentes conjuntos.
A interação está diretamente ligada tanto à Modelo de Serviço Lógico e a Modelo de Integração Lógica.
Gestão de Dados
Ferramentas e sistemas que fornecem os dados necessários onde, quando, como, com a qualidade, confiança e segurança certas.
Assim como a interação, decisões simples impulsionarão a qualidade, a segurança, o risco e a sustentabilidade dos dados.
Navegar pelos tipos de modelos de arquitetura de aplicativos
Navegar fornece um modelo de arquitetura de ponta a ponta. Criamos esse modelo de ponta a ponta por meio de tipos de modelos discretos. Um tipo de modelo pode oferecer suporte a análises específicas ou focar em um aspecto separado do modelo de ponta a ponta. Em termos simples, um tipo de modelo é um tipo específico de modelagem.
Nós construímos em torno de quatro tipos regulares de modelos de arquitetura de aplicativos:
- Modelo de Sistema de Informação
- Modelo de Aplicação Lógica
- Modelo de Serviço de Informação Lógica
- Modelo de Integração Lógica
Esses modelos especializados se combinam para desenvolver o cenário EA seguindo a melhor prática de estendê-lo incrementalmente, um projeto de arquitetura por vez.
O uso de tipos de modelos impulsiona a consistência e a reutilização, impulsionando a produtividade e a consistência em uma equipe de EA.
Navegar Modelo Tipo Descrição
Cada tipo de modelo é definido por:
- Propósito: Por que esse tipo de modelo existe e quais perguntas ele pretende responder.
- Alcance:Delineando os limites do que é incluído e excluído dentro do tipo de modelo.
- Conteúdo e Estrutura: Os componentes, relacionamentos e propriedades que devem ser usados ao criar instâncias de um tipo de modelo.
- Abordagem de Modelagem: Orientação sobre como incluir ou excluir o que é necessário para focar em aspectos específicos relevantes aos objetivos.
- (Opcional) Relacionamento com outros tipos de modelos: Descreve a finalidade do link e qual relacionamento é usado para conectar os dois modelos.
Modelo de Sistema de Informação
Escopo do Modelo de Sistema de Informação
Fornece uma representação holística do cenário de sistemas automatizados, ilustrando os principais sistemas de informação (como CRM ou sistema SCADA).
Nós usamos sistemas automatizados deliberadamente. Caminhões autônomos, IoT e aplicativos são todos sistemas automatizados
Um forte Modelo de Sistemas de Informação fornece uma entendimento compartilhado do cenário de aplicações. Ele estrutura as conversas por meio de um entendimento comum. Use este modelo para fornecer uma direção ampla ao Portfólio de Sistemas de Informação
Orientação sobre o Modelo de Sistema de Informação
Em toda a empresa
- 10-20 Sistemas Principais
Projeto de arquitetura para todo o departamento
- Espere de 5 a 10 sistemas principais
Iniciativa de Transformação
- Espere de 5 a 15 sistemas principais
Propriedades de Sistemas de Informação
-
-
Como abordaremos a compra ou construção (Commercial Suite, Commercial BoB, Opensource Suite, Opensource BoB, Custom Evolution, Custom Cloud-Ready, Custom, Saa)
-
Agilidade
-
-
Quanta pressão de mudança inesperada? A pressão de mudança inesperada advém de ameaças e oportunidades. Ela é maior em sistemas diretamente vinculados à proposta de valor, aos produtos e aos serviços.
-
Resiliência
-
-
Quanta resiliência é necessária?
-
Duplicação
-
-
Queremos duplicação? Aceitaremos duplicação? Ou pagaremos mais para evitar duplicação?
-
Padronização
-
- Pagaremos mais para exigir padronização? Aceitaremos variações? Ou exigiremos especialização?
Hospedagem
Modelo de Aplicação Lógica
A funcionalidade do modelo se divide em três grupos:
- Funcionalidade necessário para fazer ou registrar o trabalho
- Funcionalidade necessário para gerenciar o trabalho
- Funcionalidade necessária necessário para gerenciar os dados
Orientação do Modelo de Aplicação Lógica
Usamos uma taxonomia simples de 2-3 níveis.
5 a 10 aplicações lógicas em um sistema de informação
Cada uma dessas aplicações lógicas de nível 1 é decomposta em 3-5
Procure atingir um ponto ideal de ~20 a 25 Aplicações Lógicas. Você deve manter o modelo gerenciável.
Menos de 25% será arquitetonicamente interessante
Os outros 75% fornecem integridade e cobertura
Propriedades lógicas do aplicativo
Agilidade
-
- Quão adaptável a ameaças e oportunidades inesperadas
Prioridade de Desenvolvimento
-
- Profundidade do Recurso, TTM ou Sustentabilidade
Resiliência
-
- O sistema precisa absorver falhas e continuar funcionando
Vida útil
-
- Qual é a vida útil necessária
Padronização
-
- Precisamos de padronização? Devemos buscar sobreposição?
Suporte offline
-
- Precisa ser executado em algum lugar? Laptop, celular, em um submarino
Modelo de Serviço Lógico
Nós chamamos isso de Modelo de serviço, por razões históricas - a linguagem da Arquitetura Orientada a Serviços nos fez repensar. Estamos falando apenas de uma 'caixa preta' que fornece um conjunto de funcionalidades e pode ser montado com outros 'caixas pretas'.
O Modelo de Serviço Lógico:
- Define Limites
- Esclarece Pontos de Integração
- Permite a montagem centrada no consumidor
- Termos do contrato de acionamento
Quais são os termos de alteração, restrições de uso e acesso
Orientação sobre Modelo Lógico de Dados
Criação de pacotes de funcionalidades para impulsionar a implementação.
Dentro do conjunto estão:
- Termos contratuais consistentes
- Abordagem consistente para entrega
- Um limite de gerenciamento de dados
- Uma fronteira de integração
Propriedades lógicas do serviço
Agilidade
-
- Quão adaptável a ameaças e oportunidades inesperadas
Duplicação
-
- Diversificado, Replicado, Compartilhado
Desenvolvimento/Aquisição
-
- Qual é o caminho certo para aquisição
Prioridade de Desenvolvimento
-
- Profundidade do Recurso, TTM ou Sustentabilidade
Resiliência
-
- O sistema precisa absorver falhas e continuar funcionando
Vida útil
-
- Qual é a vida útil necessária
Padronização
-
- Precisamos de padronização? Devemos buscar sobreposição?
Suporte offline
-
- Precisa ser executado em algum lugar? Em um laptop, celular, em um submarino?
Modelo de Integração Lógica
O Modelo de Integração Lógica explica o que acontece entre Sistemas de Informação ou Serviços Lógicos.
Ela aborda todos os limites importantes. Não apenas os fluxos automatizados de informações.
Costumava ser
- Definir padrões de integração e arquiteturas de referência
- Expor Transformação de Dados
- Aplicar requisitos de dados (segurança, linhagem, origem)
Orientação do Modelo de Integração Lógica
Construímos um modelo formal de integração lógica que define as interfaces e o 'corretor no meio, ou use uma declaração simples de um padrão de arquitetura. O modelo formal explicará um caso único ou será usado como um arquitetura de referência e a base dos padrões de integração.
Propriedades de Integração Lógica
Agilidade
-
- Quão adaptável a ameaças e oportunidades inesperadas
Duplicação
-
- Diversificado, Replicado, Compartilhado
Provedor
-
- Interno, Externo
Resiliência
-
- O sistema precisa absorver falhas e continuar funcionando
Vida útil
-
- Qual é a vida útil necessária
Padronização
-
- Precisamos de padronização? Devemos buscar sobreposição?
Técnico Ajustar
-
- Essa integração precisa atender a requisitos técnicos especiais?
Tudo gira em torno das necessidades de dados
Sim, a arquitetura do seu aplicativo gira em torno de necessidades de dados— os aplicativos existem para processar e gerenciar dados.
Sem dados não precisamos de software.
Sua atividade empresarial criou, combina e consome dados. Dados usados para gerenciar o processo. Dados usados para registrar a atividade. Ou dados centrais para a atividade empresarial.
Na aplicação e atividade empresarial você precisa combinar
- fonte e necessidade
A origem e a necessidade definem o fluxo, que impulsiona o gerenciamento de dados - gerenciamento de dados
Qualidade, fluxo e segurança definem os recursos de gerenciamento de dados necessários
Lembrar:
As necessidades de dados abrem caminho através de cenários de aplicações fragmentados
Os dados precisam quebrar silos
As necessidades de dados impulsionam fluxos de dados reais
Conclusão sobre o que é arquitetura de aplicação?
A arquitetura do aplicativo é um contribuidor fundamental para o arquitetura de sistemas de informação. Arquitetura de Sistemas de Informação é a domínio de arquitetura que alinha gerenciamento de dados, funcionalidade, e dados.
A arquitetura do aplicativo usa quatro elementos:funcionalidade, conjunto, interação, e gerenciamento de dados.
Quatro modelos de arquitetura corporativa descreva a arquitetura do seu aplicativo:
- Modelo de Sistema de Informação
- Modelo de Aplicação Lógica
- Modelo de Serviço de Informação Lógica
- Modelo de Integração Lógica
A prática comum concentra-se na funcionalidade e na integração sem compreender as necessidades, o fluxo e o gerenciamento de dados necessários. Isso inevitavelmente gera complexidade e dívida técnica.
As melhores práticas lideram com dados e garantem a arquitetura de aplicativos está focado no estrutura e interação dos aplicativos que ... gerenciam os ativos de dados.
Sabemos que a arquitetura de aplicações permite grandes arquitetura empresarial. A funcionalidade, o fluxo de dados e o gerenciamento de dados permitem que você arquitetura de negócios.
Sem sucesso transformação digital serão construídos com base na funcionalidade. Eles são sempre construídos com base em dados.