TOGAF ADM Fase C — Desenvolver a Arquitetura do Aplicativo
Num relance
- TOGAF Fase C em ação
- O que é Arquitetura de Aplicação
- Qual é o Papel do Arquiteto Corporativo na Fase C?
- Qual é o papel do arquiteto de aplicativos?
- Qual é o papel do arquiteto de segurança na arquitetura de aplicativos?
- Qual é o papel da equipe de EA na arquitetura de aplicativos?
Considerações Finais sobre o TOGAF ADM Fase C - Arquitetura do Aplicativo
Visão geral do TOGAF ADM
O O TOGAF ADM é uma abordagem lógica para a criação de conhecimento. Conhecimento utilizado para desenvolver um arquitetura empresarial que orienta mudanças efetivas. Então, conhecimento para garantir que o valor esperado seja alcançado.
O TOGAF ADM é dividido em Fases, cada Fase é focada na criação de conhecimento que é usado para:
- selecione o caminho a seguir e o alvo
- executar governança de implementação
- avaliar a jornada à frente e corrigir o curso
O que é TOGAF Fase C?
A Fase C avança ainda mais no conceito de domínios de arquitetura. Esta fase desenvolve a arquitetura do aplicativo e a arquitetura de dados. Formalmente, a Fase C divide o tratamento do Domínio da Arquitetura de Dados e do Domínio da Arquitetura de Aplicativos individualmente.
Assim como a Fase B, a Fase C se baseia na Visão da Arquitetura. Há uma reviravolta, a Fase C tem uma obrigação adicional de habilitar a arquitetura de negócios. Isso não está tratando a arquitetura de negócios como requisitos, mas sim para confirmar que as metas de resumo em desenvolvimento se mantêm unidas.
Mudanças em um domínio geram restrições e requisitos em outros domínios. O objetivo é encontrar o melhor conjunto de mudanças em todos os domínios.
Usando as etapas da Fase C, os arquitetos desenvolvem o seguinte conhecimento:
- qual arquitetura de referência irá acelerar o desenvolvimento da arquitetura
- quais pontos de vista conduzirão a análise relevante para que as partes interessadas selecionem entre alternativas de arquitetura
- quais modelos de arquitetura de aplicativos e modelos de dados ajudarão a encontrar a origem da deficiência e as mudanças que a resolverão
- onde mudanças na arquitetura do aplicativo geram mudanças em outros domínios
- onde mudanças em outros domínios geram mudanças na arquitetura do aplicativo
Cria os seguintes produtos de obras centrais:
- visões que analisam a arquitetura dos sistemas de informação do candidato em termos das preocupações das partes interessadas
- que uma arquitetura de aplicativo alvo atual e candidata
- lacunas na arquitetura da aplicação
- produtos de trabalho candidatos que mudam o negócio
A Fase C se concentra em coisas como design de aplicativo, fluxo de dados, integração, abordagem de desenvolvimento, construir vs comprar e planejamento de mudanças. A avaliação e o entendimento adequados desta fase são essenciais.
O que é TOGAF Fase C?
No TOGAF Phase C, você está criando a arquitetura do aplicativo. Arquitetos de aplicativos liderar o desenvolvimento da arquitetura de sua aplicação. O decisões arquitetônicas feitos na Fase C para arquitetura de aplicativos interagirem com decisões tomadas em cada domínio de arquitetura empresarial.
Fase C em ação
A Arquitetura do Aplicativo ajudará a responder às seguintes perguntas:
- Como o portfólio de aplicativos permite a captura de valor – Modelo de Desenvolvimento de Aplicativos
- Onde o custo é injetado no Portfólio de TI - Modelo Funcional
- Onde a rigidez é injetada no Portfólio de TI - Modelo de Integração
- Como a empresa funciona – Modelo de sistema
- Sistemas necessários para entregar o produto ou serviço – Modelo do produto
- As coisas que uma organização deve ser capaz de fazer - Modelo Funcional
- O fluxo de informações necessário para realizar as atividades de uma empresa - Modelo de Integração
- As atividades completas que uma empresa realiza, normalmente agrupadas para mostrar como elas se relacionam umas com as outras – Modelo de serviço
- O que é o portfólio de software – Modelo Físico
Tenha sempre em mente que você está buscando melhorar a organização. A melhoria requer mudança e entrega valor. O valor e o custo da mudança podem ser medidos. A incerteza sempre diminui o valor potencial. A incerteza sempre aumenta o custo. Tratamos a incerteza como um impacto geométrico. Um pouco de incerteza diminui muito o valor potencial.
Ao ler, tenha em mente que há muitos usos dos mesmos termos. Procure o propósito do modelo e não fique preso quando o rótulo for diferente do que você chamaria. Por exemplo, o que você chama de modelo funcional, outra pessoa chamará de serviço. Na nossa consultoria em arquitetura empresarial, sempre focamos no que estamos tentando entender, não no nome do modelo.
Diferentes modelos explicarão diferentes aspectos da empresa. Juntos, os modelos e as mudanças necessárias formam a arquitetura do aplicativo.
O que é Arquitetura de Aplicativos?
Uma arquitetura de aplicativo é uma descrição de seu portfólio completo de software que informa quando comprar, quando usar SaaS e quando construir. Ele diz onde você deve colocar limites entre os sistemas. Ele informa como você abordará o ciclo de vida do software.
Podemos garantir que sua arquitetura de aplicativos atual não esteja alinhada com sua arquitetura de negócios. Uma arquitetura de aplicativo requer um arquitetura de negócios. O desenvolvimento da arquitetura de negócios exige que os arquitetos de aplicativos se unam a eles, envolvendo-se com as partes interessadas.
Com a parte interessada e o arquiteto de negócios, o arquiteto de aplicativos explora como as escolhas de software permitem e restringem os objetivos da organização. Consideramos possíveis melhorias para entender o impacto imediato e de médio prazo. Juntas, as mudanças potenciais que entregam muito pouco, exigem muito trabalho ou têm muita incerteza são descartadas do roteiro de arquitetura.
Quando estamos desenvolvendo equipes de arquitetura corporativa, dizemos ao arquitetos empresariais dois fatos centrais sobre o TOGAF Fase C - Arquitetura de Aplicativos. Primeiro, até que você tenha um Modelo de Desenvolvimento de Aplicativos, você não pode prosseguir. Até que você saiba como suas escolhas de aplicativos habilitam e restringem sua arquitetura de negócios, os detalhes de seus aplicativos são inúteis. Em segundo lugar, se eles acreditam que precisam pular para a funcionalidade e integração do aplicativo, eles sempre desenvolverão uma arquitetura de aplicativo de baixa qualidade.
Em um moderno empresa transformada digitalmente, todos os domínios de arquitetura interagem. As escolhas em um domínio habilitam, entregam ou bloqueiam resultados em outro domínio. A maioria dos objetivos de negócios depende Arquitetura de TI certa. Ironicamente, só podemos desenvolver a arquitetura de aplicativo correta se tivermos uma arquitetura de negócios sólida.
Qual é o papel do Arquiteto Corporativo na Fase C?
Na Fase C do TOGAF, o papel do arquiteto corporativo é proteger todo o valor. Dependendo das habilidades dos arquitetos de domínio, o arquiteto corporativo precisa preencher. Por exemplo, um Arquiteto de Aplicativos pode não ver o impacto das mudanças na arquitetura de negócios. Ou eles podem não articular um requisito em termos sobre os quais o arquiteto de segurança possa agir.
O papel mais importante do arquiteto corporativo é cruzar fronteiras. Sejam eles limites de domínio, habilidade ou autoridade, o arquiteto corporativo precisa ultrapassá-los.
Qual é o papel do Arquiteto de Aplicativos na Fase C?
Na Fase C do TOGAF, esperamos que o Arquiteto de Aplicativos entregue a arquitetura de domínio. Isso requer o desenvolvimento de modelos que mostrem a origem da deficiência e como superá-la. Eles conduzirão a análise de trade-off com as partes interessadas para determinar a arquitetura de destino.
O arquiteto de aplicativos precisará colaborar com os outros arquitetos de domínio.
Desligue a arquitetura de negócios. Conheça e entenda o Modelo Operacional e os atributos de Competência e Automação do Modelo de capacidade.
Qual é o papel do Arquiteto de Segurança na Fase C?
Na Fase C do TOGAF, esperamos que o Arquiteto de Aplicativos entregue a arquitetura de domínio. Isso requer o desenvolvimento de modelos que mostrem a origem da deficiência e como superá-la. Eles conduzirão a análise de trade-off com as partes interessadas para determinar a arquitetura de destino.
O arquiteto de aplicativos precisará colaborar com os outros arquitetos de domínio.
Desligue a arquitetura de negócios. Conheça e entenda o Modelo Operacional e os atributos de Competência e Automação do Modelo de capacidade.
Tenha em mente que as deficiências em um domínio geralmente são resolvidas em outro, e as mudanças em um domínio geralmente impõem custos e mudanças em outro.
Qual é o papel da equipe EA na arquitetura de aplicativos
Tenha em mente que as deficiências em um domínio geralmente são resolvidas em outro, e as mudanças em um domínio geralmente impõem custos e mudanças em outro.
Interação com TOGAF Fase B, Fase D e Fase E
As abordagens em cascata não funcionam. A arquitetura corporativa de melhores práticas não é uma atividade em cascata. A única abordagem bem-sucedida requer o desenvolvimento da arquitetura de negócios, arquitetura de aplicativos, arquitetura de dados, arquitetura de tecnologia e arquitetura de segurança simultaneamente. O desenvolvimento simultâneo requer uma abordagem ágil o suficiente para testar as restrições em cascata.
A sequência clássica implícita em muitos diagramas TOGAF ADM é a ordem em que podemos fechar o desenvolvimento da arquitetura, não iniciá-lo.
Não caia na ilusão de que 'o negócio' está de alguma forma separado de seus aplicativos, dados e infraestrutura. Isso não era verdade no passado, e em uma empresa digital moderna é risível. Essa ilusão é a maneira mais rápida de eliminar agilidade empresarial ou a chance de transformação digital sucesso.
Os arquitetos de aplicativos têm um papel crítico em uma equipe de arquitetura corporativa. Nada acontece em uma empresa digital moderna sem software. Escolhas de aplicativos ruins irão prejudicar 'o negócio.' Os arquitetos de aplicativos são especialistas em um domínio de arquitetura. Eles não podem arquitetar seu domínio sem um envolvimento regular com arquitetos de negócios, dados, tecnologia e arquitetos de segurança.
Baixe o Guia do Líder Empresarial para IA
Baixe o Guia do Líder Empresarial para Inteligência Artificial As organizações que aplicam com sucesso tecnologia inovadora têm uma vantagem competitiva. A tecnologia inovadora não vem com padrões de sucesso estabelecidos e melhores práticas. A tecnologia inovadora é nova e […]
Baixe a Introdução ao Padrão TOGAF, 10ª Edição
Download Introdução ao TOGAF® Standard, 10ª edição O TOGAF Standard, 10ª edição facilita a adoção das melhores práticas de arquitetura corporativa. Ele separa os conceitos universais das melhores práticas comprovadas. O padrão ressalta onde […]
Baixe o guia de planejamento baseado em capacidade
Baixe o Guia de planejamento baseado em capacidade Sempre busque obter valor. Metade de uma melhoria é desperdício de 100%! Ninguém ensina uma águia a engatinhar, andar ou correr. Águias voam! Baixe Ensine suas Águias a Voar: Planejamento Baseado em Capacidade […]
Baixe o Guia de Avaliação de Capacidade de Arquitetura de Negócios
Baixe o Guia de Avaliação de Recursos de Arquitetura de Negócios Baixe um Guia de Avaliação de Recursos de Arquitetura de Negócios. O planejamento baseado em capacidade é uma das técnicas de melhoria de arquitetura de negócios mais poderosas. A melhor prática de planejamento baseado em capacidade usa a capacidade como uma […]
Baixar exemplos de princípios de arquitetura corporativa
Baixar exemplos de princípios de arquitetura Baixe um exemplo de princípios de arquitetura corporativa. Os princípios da Arquitetura Corporativa identificam como abordar um problema ou decisão. A abordagem sempre o leva em direção às suas prioridades duradouras. Baixe exemplos de princípios de arquitetura corporativa […]
Baixe o Guia de Governança da Arquitetura Corporativa
Baixe o Guia de Governança da Arquitetura Corporativa Baixe o Guia de Governança da Arquitetura Corporativa para entender as melhores práticas para direcionar e controlar o desenvolvimento da arquitetura e mudar para obter os resultados esperados. Baixe o Guia de Governança de Arquitetura Corporativa […]
Baixe Integração TOGAF e SABSA
Download TOGAF e Integração SABSA Junte SABSA, a melhor estrutura de arquitetura de segurança do mundo, e TOGAF, a estrutura de arquitetura corporativa padrão do setor. Download Integração TOGAF e SABSA Integração TOGAF e SABSA Inclui SABSA usa um […]
Baixar Arquitetura de referência de recursos de arquitetura corporativa
Baixar Arquitetura de Referência de Capacidade de Arquitetura Corporativa A Arquitetura de Referência de Capacidade de Arquitetura Corporativa acelerará o estabelecimento e aprimoramento de sua Equipe EA. Projete sua equipe de arquitetura corporativa para o sucesso. Identifique e aprimore a arquitetura da sua empresa […]
Faça o download do relatório Agile Enterprise Architecture
Baixe o Relatório de Arquitetura Corporativa Agile O Relatório de Arquitetura Corporativa Agile abrange nossa experiência – a Arquitetura Corporativa Agile é real, prática e valiosa. Nós fazemos isso todo dia. Os relatórios de campo fazem a ponte entre os conceitos teóricos e […]
Faça o download do estudo de caso da arquitetura corporativa ágil
Faça download do estudo de caso da arquitetura corporativa ágil Faça download do estudo de caso da arquitetura corporativa ágil para ver um exemplo de desenvolvimento de um recurso de EA e uma arquitetura útil ao mesmo tempo. Cobrimos todos os seis casos de uso […]
Fase C Conhecimento Essencial
Todas as Fases do TOGAF ADM levam você a desenvolver o conhecimento que você precisa. O resultado da Fase C é a arquitetura de aplicativo candidata incluída na arquitetura de sistemas de informação candidata.
| Saída e Resultado | Conhecimento Essencial |
| O arquitetura de aplicação arquitetura de domínio aprovados pelas partes interessadas para o problema que está sendo abordado, com um conjunto de lacunas, e trabalhar para eliminar as lacunas compreendidas pelas partes interessadas. | Como o portfólio de software atual não atende às preferências das partes interessadas?
O que deve mudar para permitir que o portfólio de software atenda às preferências das partes interessadas? (Lacunas) Que trabalho é necessário para realizar as mudanças consistentes com o valor adicional que está sendo criado? (Pacote de trabalho) Como a prioridade e a preferência das partes interessadas se ajustam em resposta ao valor, esforço e risco de mudança. (Requisitos das Partes Interessadas) |
Tabela 4 de Guia da Série TOGAF: Guia do Arquiteto Corporativo para Desenvolvimento de Arquitetura
Fase C Nus Bones
Na Fase C, podemos simplificar o trabalho de um arquiteto de aplicativos para determinar como uma empresa deve ser melhor. Isso requer entender em que ela está tentando ser boa, onde está aquém do melhor e o que deve mudar para permitir ser o melhor.
Os ossos da Fase C são:
- Saber como o portfólio de aplicativos permite a captura de valor
Toda organização tem uma cadeia de valor. Atividade que transforma uma entrada em algo mais valioso para seus clientes. Os aplicativos realizam a criação de valor ou fornecem manutenção de registros. Tradicionalmente, quase todos os softwares forneciam manutenção de registros.
Você deve otimizar seu software para função - criação de valor ou manutenção de registros. Assuma a manutenção de registros. Não confunda o importante papel da manutenção de registros com a criação de valor.
Conhecer a fonte de custo e complexidade
Todo portfólio de aplicativos gera custos e complexidade. Pensamos no software como um relógio complexo que foi montado ao longo do tempo. Conectamos tudo a tudo. Com produtos digitais e serviços de TI onipresentes entendendo ITFM é uma habilidade fundamental.
Você deve otimizar seu portfólio principal para eliminar custos e complexidade sustentados. Você deve habilitar agilidade empresarial. As organizações digitais modernas só podem melhorar no ritmo do software.
- Saber selecionar software
Existem quatro modelos de software: SaaS, suítes empresariais, pacotes comerciais especializados e desenvolvimento personalizado. Cada um tem um modelo de custo e otimização diferente. Você precisa aplicar o modelo de software certo nos lugares certos.
- Saber quando o software faz parte de 'o produto'
Nossas organizações entregam um produto ou serviço. Software que é 'o produto' difere muito do software que dá suporte ao negócio.
- Conhecendo o fluxo de informações
As pessoas são infinitamente flexíveis. Podemos decidir compartilhar informações. Podemos proativamente ver uma situação e reagir. O software faz exatamente o que é dito. O software só faz o que é dito.
O fluxo de informações acontece em torno do software para fazer a coisa certa. Esse tipo de fluxo de informações quebra a agilidade da empresa. Eles paralisam a eficiência. Esses fluxos geram custos.
- Conhecendo as expectativas do software
Às vezes, precisamos de um registrador casual. Às vezes precisamos de um sistema autônomo. Na maioria das vezes precisamos de algo que ajude sem muita sobrecarga. Alavancamos os conceitos e atributos em modelos de capacidade para orientar as escolhas sobre nossa arquitetura de aplicativos. Veja o Guia de Avaliação de Capacidade de Arquitetura de Negócios.
- Saiba o que a organização deve fazer
Toda empresa tem um conjunto de processos que deve executar: criação de valor primário, suporte e administrativo. Todos eles precisam de software. Cada um deles cria e produz informação. Você precisa saber o que são, as informações que consomem e quem as faz.
- O que deve mudar para entregar o melhor portfólio de aplicativos?
Desenvolvemos arquitetura de aplicativos para melhorar uma organização. A maioria das mudanças não faz uma diferença material. A maioria das mudanças mexe nas bordas. Concentre seu tempo em mudanças materiais que geram agilidade, custo ou criação de valor corporativos significativos.
Os três fundamentos de conclusão da Fase C:
- Primeiro, o que precisa mudar? Mudança de foco, design organizacional, requalificação, terceirização, insourcing, automação. Todas essas são mudanças. Nós as fazemos para melhorar uma organização.
- Segundo, quando deve mudar? Há dependências? E quanto às pré-condições? Você está mudando o set-the-stage para uma mudança posterior?
- Terceiro, como você saberá se a mudança foi bem-sucedida? Qual é seu teste de governança para sucesso? Como você protegerá o valor?
Os stakeholders da arquitetura empresarial são donos de todas as decisões sobre o que deve mudar e quando. O arquiteto de aplicação é dono da descrição dos testes de governança para permitir que os stakeholders direcionem o projeto de mudança, o segundo e o terceiro resultados.
Treinamento em Arquitetura Corporativa e Treinamento TOGAF
Treinamento de Arquitetura Corporativa Personalizada
Treinamento personalizado de arquitetura corporativa O treinamento personalizado de arquitetura corporativa aborda o desenvolvimento profissional que sua equipe EA precisa. Bons arquitetos corporativos usam um amplo conjunto de habilidades, métodos, além de conhecimento de domínio especializado para desenvolver […]
Curso de Treinamento Avolution ABACUS
Treinamento Avolution ABACUS Uma arquitetura empresarial eficaz depende de modelagem e análise formal. Oferecemos treinamento Avolution ABACUS com arquitetos empresariais práticos. Os alunos adquirem habilidades e conhecimento para criar arquiteturas corporativas e de domínio integradas neste [...]
Kickstart do arquiteto corporativo
Enterprise Architect's Kickstart Precisamos manter nossas habilidades atualizadas. Mais agora do que nunca. Use o Enterprise Architecture Kickstart para melhorar sua capacidade de entregar arquitetura empresarial transformadora. Este kickstart de 90 dias é como a Conexiam Consulting […]
Curso de treinamento em arquitetura empresarial TOGAF
Você quer treinamento para a Certificação TOGAF? Demonstre seu conhecimento de arquitetura corporativa com a certificação TOGAF Curso de treinamento em arquitetura empresarial TOGAF® Dê um passo importante para ser um arquiteto corporativo melhor com o padrão TOGAF, 10º [...]
Educação Online Eficaz
Educação Online Eficaz A educação online eficaz funciona. Os alunos acessam o melhor instrutor disponível. Os alunos controlam o ritmo de seu aprendizado. Os instrutores podem compartilhar material suplementar rico sem distrair do tópico principal. Distância eficaz […]
Curso de Formação em Arquitetura de Negócios
Treinamento em Arquitetura de Negócios A arquitetura empresarial eficaz depende da arquitetura de negócios. O curso oferece aos alunos as habilidades e conhecimentos para desenvolver arquitetura de negócios em um ambiente de arquitetura corporativa. A arquitetura de negócios envolve a descrição da estrutura do [...]
Entregas da Arquitetura de Aplicativos TOGAF ADM Fase C
Um resultado central da Fase C é uma arquitetura de aplicativo. Essa é uma parte da arquitetura corporativa completa.
Entregas de arquitetura de aplicativos da fase C do TOGAF e casos de uso de arquitetura empresarial
Existem quatro propósitos principais para desenvolver a arquitetura corporativa. Diferentes entregáveis da Fase C do TOGAF têm importância diferente em cada finalidade.
| Arquitetura para apoiar a estratégia | Arquitetura para dar suporte ao portfólio | Arquitetura para Apoio ao Projeto | Arquitetura para dar suporte à entrega de soluções | |
| Produto de Trabalho da Fase C: Arquitetura de Aplicação Candidata | Entrega chave
O uso principal é a compreensão das partes interessadas do objetivo e do trabalho. O uso secundário é a criação da Especificação de Requisitos de Arquitetura para Arquitetos |
Entrega chave
O uso principal é a compreensão das partes interessadas do objetivo e do trabalho. O uso secundário é a criação da Especificação de Requisitos de Arquitetura para Arquitetos |
Antes do início do projeto e finalização do business case
O uso principal é a criação da Especificação de Requisitos de Arquitetura para Implementadores |
Antes da contratação de parceiros de execução (incluindo fornecedores internos)
O uso principal é a criação da Especificação de Requisitos de Arquitetura para Implementadores |
| Produto de Trabalho da Fase C: Itens do Roteiro Candidato | Entrega chave
O uso principal é a compreensão do trabalho pelas partes interessadas. O uso secundário é a criação de restrições para Arquitetos |
Entrega chave
O uso principal é a compreensão das partes interessadas sobre o trabalho e a dependência. O uso secundário é a criação de restrições para Arquitetos |
Uso limitado Pode ser usado como entrada para projetos com várias alterações interativas |
Antes da contratação de parceiros de execução (incluindo fornecedores internos).
O uso principal é a identificação da mudança necessária e as preferências de como executar a mudança, para gerenciar a seleção e o engajamento do parceiro de entrega de soluções |
| Produto de Trabalho da Fase C: Especificação de Requisitos de Arquitetura | Uso limitado
Normalmente, os arquitetos podem inferir restrições da arquitetura superior. |
Uso limitado
Normalmente, os arquitetos podem inferir restrições da arquitetura superior. |
Entrega chave
Antes da conclusão do início do projeto |
Entrega chave
Antes da contratação e contratação |
Tabela 3 Guia da Série TOGAF: Guia do Arquiteto Corporativo para Desenvolvimento de Arquitetura
Arquitetura de aplicativo do candidato
Existem quatro propósitos principais para o desenvolvimento de arquitetura corporativa. Diferentes modelos têm importância diferente em cada finalidade.
Componentes do roteiro de arquitetura de aplicativos candidatos
O que deve mudar? Se você estiver alterando o Modelo de Desenvolvimento de Aplicativos, a diferença entre o atual e o alvo é o Candidato ao Roteiro. Assim é tudo o que é necessário para permitir essa mudança.
Muitas vezes usamos um modelo de sistema para resumir a mudança. O Modelo do Sistema permite abstração suficiente do software real para ter uma conversa de planejamento e execução. Geralmente usamos pontuações e pacotes de trabalho para articular uma mudança. Para obter mais informações sobre como usar pontuações, consulte o Guia de Avaliação de Capacidade de Arquitetura de Negócios.
Usamos todos os componentes do roteiro de arquitetura em TOGAF Fase E - Roteiro de Arquitetura.
Especificação de Requisitos de Arquitetura de Aplicativo Candidato
Defina como você avaliará a mudança. Como será avaliada a melhoria?
Muitas vezes usamos pontuações em nossos modelos para descrever os requisitos. Cada requisito é uma medida de eficiência, automação, agilidade ou desempenho. Então, quando estamos trabalhando em TOGAF Fase G realizando governança de arquitetura com um projeto de mudança usamos essas pontuações para avaliar projetos e implementações.
Vá mais longe com o processo e método de arquitetura empresarial de melhores práticas
Melhor prática arquitetura empresarial a partir de Conexiam Navigate
Roteiro de arquitetura corporativa como design
Enterprise Architecture Roadmap como Design Um Architecture Roadmap é uma ferramenta de planejamento que ajuda os tomadores de decisão de uma organização. Um Architecture Roadmap dinâmico é projetado para ajudá-los a desenvolver e percorrer o melhor caminho a seguir. Ele também […]
Desbloqueando seu potencial de negócios: como criar um mapa de capacidade eficaz
Desbloqueando seu potencial de negócios: como criar um mapa de capacidade eficaz Você está lutando para identificar os recursos necessários para levar sua empresa ao próximo nível? Você acha difícil alinhar recursos […]
Desenvolvendo uma visão de arquitetura
Desenvolver uma Arquitetura Corporativa de Visão de Arquitetura é uma bússola essencial. Ajuda as organizações a navegar pelas complexidades da tecnologia, estratégia e operações. O núcleo da arquitetura corporativa é uma abordagem sistemática. O objetivo é garantir […]
Criação de um Conselho de Revisão de Arquitetura Moderna
Estabelecendo um Conselho de Revisão de Arquitetura Moderna Estabelecer um conselho de revisão de arquitetura moderna requer a criação de um processo de governança dinâmico e o estabelecimento de um órgão decisório de alto nível e de apoio. O objetivo é estabelecer uma governança de arquitetura eficaz sem burocracia. […]
Descubra o poder dos padrões de arquitetura empresarial
Descobrindo o poder dos padrões de arquitetura empresarial: um guia abrangente Toda organização deseja melhorar. Simplifique suas operações. Aumente a agilidade empresarial. Alinhe a mudança com suas estratégias. Tenha sucesso na transformação digital. Arquitetura Corporativa, uma disciplina [...]
Fazendo escolhas mais inteligentes: por que sua empresa precisa de decisões arquitetônicas
Fazendo escolhas mais inteligentes: por que sua empresa precisa de decisões arquitetônicas As empresas são constantemente confrontadas com o desafio de tomar decisões cruciais. Todos os dias, as decisões, incluindo práticas operacionais e seleções de tecnologia, têm um impacto significativo em um […]
Comparação da estrutura de arquitetura corporativa: qual é a certa para você?
Comparação de frameworks de arquitetura empresarial: qual é o certo para você? Não existe um modelo único para todos os negócios. Nem em frameworks de arquitetura empresarial. Compare os méritos de frameworks populares para determinar qual framework otimizado é o certo para você. Enquanto […]
Noções básicas sobre arquitetura empresarial e ágil
Noções básicas sobre arquitetura empresarial e ágil Tanto a arquitetura ágil quanto a corporativa são projetadas para reduzir riscos. O desenvolvimento ágil de software se destaca na construção de algo que nunca tivemos antes e não sabemos como construir. […]
Garantindo Alinhamento e Responsabilidade: O Papel Crucial das Listas de Verificação de Governança da Arquitetura Empresarial
Garantindo Alinhamento e Responsabilidade: O Papel Crucial das Listas de Verificação de Governança de Arquitetura Corporativa As Listas de Verificação de Governança de Arquitetura Corporativa simplificam os processos de governança de arquitetura corporativa. O processo de governança precisa aprovar a arquitetura alvo e fornecer governança de implementação. Uma empresa robusta […]
Gestão de Trabalho de Arquitetura Empresarial
Enterprise Architecture Work Management O Enterprise Architecture Work Management é crucial para o sucesso diário de uma Equipe de Arquitetura Empresarial. Os arquitetos devem fornecer orientação útil antes que as partes interessadas tomem decisões informadas. Os arquitetos corporativos precisam traduzir o […]
Modelos, ferramentas e técnicas de arquitetura de aplicativos
O TOGAF ADM Fase C entrega a Arquitetura de Sistemas de Informação. Esta Fase existe para desenvolver a arquitetura de aplicativos e a arquitetura de dados que compõem os sistemas de informação. No TOGAF, o primeiro passo é determinar as visualizações necessárias e os modelos necessários.
As Preocupações das Partes Interessadas identificarão os pontos de vista. Existem sete modelos de arquitetura de aplicativo central.
- Modelo de desenvolvimento de aplicativos que descreve o método aceitável em que um sistema será desenvolvido
- Modelo de sistema que captura os grandes sistemas em que seu portfólio de aplicativos foi projetado
- Modelo Funcional que descreve todas as coisas que você precisa que seu portfólio de software execute
- Modelo de Produto que identifica a funcionalidade utilizada nos produtos e serviços da sua organização, bem como aqueles que os administram
- O Modelo de Integração descreve como as informações fluem pelo seu portfólio de aplicativos
- O modelo de serviço divide seu portfólio de aplicativos em caixas pretas e permite garantir que cada serviço tenha agilidade, automação e outros atributos necessários
- O Modelo Físico identifica os aplicativos reais, comerciais, SaaS ou personalizados, em seu portfólio de aplicativos
A Arquitetura do Aplicativo ajudará a responder às seguintes perguntas:
- Como o portfólio de aplicativos permite a captura de valor – Modelo de Desenvolvimento de Aplicativos
- Onde o custo é injetado no Portfólio de TI - Modelo Funcional
- Onde a rigidez é injetada no Portfólio de TI - Modelo de Integração
- Como a empresa funciona – Modelo de sistema
- Sistemas necessários para entregar o produto ou serviço – Modelo do produto
- As coisas que uma organização deve ser capaz de fazer - Modelo Funcional
- O fluxo de informações necessário para realizar as atividades de uma empresa - Modelo de Integração
- As atividades completas que uma empresa realiza, normalmente agrupadas para mostrar como elas se relacionam umas com as outras – Modelo de serviço
- O que é o portfólio de software – Modelo Físico
Tenha sempre em mente que você está buscando melhorar a organização. A melhoria requer mudança e entrega valor. O valor e o custo da mudança podem ser medidos. A incerteza sempre diminui o valor potencial. A incerteza sempre aumenta o custo. Tratamos a incerteza como um impacto geométrico. Um pouco de incerteza diminui muito o valor potencial.
Ao ler, tenha em mente que há muitos usos dos mesmos termos. Procure o propósito do modelo e não fique preso quando o rótulo for diferente do que você chamaria. Por exemplo, o que você chama de modelo funcional, outra pessoa chamará de serviço. Na nossa consultoria em arquitetura empresarial, sempre focamos no que estamos tentando entender, não no nome do modelo.
Diferentes modelos explicarão diferentes aspectos da empresa. Juntos, os modelos e as mudanças necessárias formam a arquitetura do aplicativo.
Padrões de arquitetura de aplicativos
Nós usamos padrões de arquitetura para aumentar drasticamente a produtividade e a qualidade do nosso desenvolvimento de arquitetura. Modelo de padrão de arquitetura nos leva a compreender a problema previsível, abordagem padrão, e as Partes difíceis. O sucesso com o padrão requer abordar o Partes difíceis (trabalho necessário, restrições e limitações).
Exemplos de padrões de arquitetura de aplicativos
Exemplos de padrões de arquitetura de aplicativos cobrem o problema de estrutura de aplicativos, migração e como projetar aplicativos.
- Estrutura do aplicativo
- Padrão MVC (Model-View-Controller)
Problema previsível— organização do código, capacidade de manutenção e testabilidade
Abordagem—separa um aplicativo em três componentes interconectados: Modelo (dados e lógica de negócios), Visualização (interface do usuário) e Controlador (lida com a entrada do usuário e atualiza o Modelo e a Visualização de acordo)
- Padrão MVC (Model-View-Controller)
- Migração de aplicativos
- Padrão Estrangulador
Problema previsível—substituindo sistemas legados
Abordagem—substituir gradualmente ou “estrangular” um sistema legado existente, construindo novos componentes em torno dele para substituir gradativamente o sistema
- Padrão Estrangulador
- Design de aplicativos (grupo de quatro padrões de aplicativos)
Como arquitetos corporativos, usamos padrões de design como restrições à liberdade das equipes de desenvolvimento de aplicativos. (Ver Arquitetura Corporativa e Ágil - Restringir Sprints)- Padrão Singleton- garante que uma classe tenha apenas uma instância e fornece um ponto global de acesso a essa instância
Modelos de Arquitetura de Aplicativos
O desenvolvimento de uma arquitetura de aplicativo exigirá o desenvolvimento de vários modelos de arquitetura corporativa. Cada um explica o portfólio de software da empresa de maneira diferente. A Arquitetura de Aplicação TOGAF Fase C tem tudo a ver com o desenvolvimento da Arquitetura Alvo por meio desses modelos. Garantir que o arquiteto de aplicativos de destino trabalhe com os outros domínios para permitir a melhor melhoria para sua empresa.
Juntos, os modelos descrevem a arquitetura do aplicativo. Na arquitetura corporativa completa, esses modelos serão vinculados a outros modelos que descrevem os outros domínios da arquitetura corporativa.
Modelo de Desenvolvimento de Aplicativos
O Modelo de Desenvolvimento de Aplicativos descreve como o software será desenvolvido. O modelo requer um modelo funcional ou físico. O Modelo Funcional é muito melhor porque é um software de identificação lógica.
Existem quatro tipos de desenvolvimento de aplicativos: SaaS, suítes corporativas, pacotes comerciais especializados e desenvolvimento personalizado. Cada tipo tem características e implicações únicas.
- As características do SaaS incluem software empacotado com interfaces bem definidas. Um terceiro controla o ciclo de vida. A personalização não está disponível.
Melhor usado para atividades de negócios que são administrativas e apoiam indiretamente a atividade de produção de valor. As rígidas restrições de software geram restrições nas atividades de negócios e ajudam a forçar a adoção de práticas padrão do setor.
- As características dos conjuntos empresariais incluem vários modelos funcionais sobrepostos, com modelo de dados definido. Interfaces e funcionalidades podem ser configuradas ou personalizadas. As personalizações invariavelmente criam custos adicionais durante o ciclo de vida. O ciclo de vida é influenciado por terceiros.
- As características dos pacotes comerciais especializados incluem foco pontual e otimização funcional para a atividade especializada. Normalmente concebido em torno de uma forma de abordar a atividade de negócios. Geralmente tem um modelo de dados único e bem definido. Interfaces e funcionalidades podem ser configuradas. A personalização pode ser possível. As personalizações invariavelmente criam custos significativos durante o ciclo de vida. O ciclo de vida é fortemente influenciado por terceiros.
- As características de desenvolvimento personalizado incluem alinhamento direto entre os limites e atividades organizacionais herdados de sua organização. Invariavelmente projetado para suportar o modelo de comunicação existente de sua organização. Foco pontual e otimização funcional para a atividade especializada. Espere um modelo de dados mal definido. Interfaces e funcionalidades devem ser customizadas. O gerenciamento do ciclo de vida geralmente é ignorado e tem um alto custo contínuo.
Melhor usado para atividades de negócios na cadeia de valor primária. A flexibilidade permite a otimização de como o valor é gerado. O uso eficaz requer a compreensão da geração de valor hoje e no futuro.
Modelo de Desenvolvimento de Aplicativos
O Modelo de Desenvolvimento de Aplicativos descreve como o software será desenvolvido. O modelo requer um modelo funcional ou físico. O Modelo Funcional é muito melhor porque é um software de identificação lógica.
Existem quatro tipos de desenvolvimento de aplicativos: SaaS, suítes corporativas, pacotes comerciais especializados e desenvolvimento personalizado. Cada tipo tem características e implicações únicas.
- As características do SaaS incluem software empacotado com interfaces bem definidas. Um terceiro controla o ciclo de vida. A personalização não está disponível.
Melhor usado para atividades de negócios que são administrativas e apoiam indiretamente a atividade de produção de valor. As rígidas restrições de software geram restrições nas atividades de negócios e ajudam a forçar a adoção de práticas padrão do setor.
- As características dos conjuntos empresariais incluem vários modelos funcionais sobrepostos, com modelo de dados definido. Interfaces e funcionalidades podem ser configuradas ou personalizadas. As personalizações invariavelmente criam custos adicionais durante o ciclo de vida. O ciclo de vida é influenciado por terceiros.
- As características dos pacotes comerciais especializados incluem foco pontual e otimização funcional para a atividade especializada. Normalmente concebido em torno de uma forma de abordar a atividade de negócios. Geralmente tem um modelo de dados único e bem definido. Interfaces e funcionalidades podem ser configuradas. A personalização pode ser possível. As personalizações invariavelmente criam custos significativos durante o ciclo de vida. O ciclo de vida é fortemente influenciado por terceiros.
- As características de desenvolvimento personalizado incluem alinhamento direto entre os limites e atividades organizacionais herdados de sua organização. Invariavelmente projetado para suportar o modelo de comunicação existente de sua organização. Foco pontual e otimização funcional para a atividade especializada. Espere um modelo de dados mal definido. Interfaces e funcionalidades devem ser customizadas. O gerenciamento do ciclo de vida geralmente é ignorado e tem um alto custo contínuo.
Melhor usado para atividades de negócios na cadeia de valor primária. A flexibilidade permite a otimização de como o valor é gerado. O uso eficaz requer a compreensão da geração de valor hoje e no futuro.
Modelo de sistema
O modelo do sistema é uma abstração de software em torno de uma atividade. Pense no 'sistema da cadeia de suprimentos' e em tudo o que está envolvido na cadeia de suprimentos. O design do seu modelo de sistema se alinhará com a forma como sua empresa é executada.
Assim como o modelo de capacidade do arquiteto de negócios, um modelo de sistema permite direcionar o pensamento para um sistema. Você pode procurar melhorar um sistema completo e, em seguida, concentrar as alterações necessárias em tudo o que compõe o sistema e interage com ele.
Modelo do produto
Um Modelo de Produto é uma versão especializada de um Modelo Funcional que destaca as funções necessárias para seus Produtos ou serviços. Um bom Modelo de Produto classificará o que é realizado em termos comparáveis.
Um bom Modelo de Produto formará a base de um arquitetura de referência para seus produtos. Você precisa especificar as funções que são centrais para o valor, uso e administração do produto. Um modelo de produto informará as escolhas do modelo de desenvolvimento de aplicativos. Você precisa de Desenvolvimento Personalizado, duplicação e uma capacidade significativamente maior de mudar quando as funções estão associadas aos seus Produtos e Serviços.
Modelo Funcional
O modelo Funcional divide seu portfólio de software em funcionalidade. Ele identifica todas as coisas que seu software precisa fazer. Bons modelos funcionais fornecem ampla cobertura.
Assim como o modelo de processo do arquiteto de negócios, um modelo funcional é frequentemente uma arquitetura de referência. Ele é poderoso quando você está buscando duplicação e integração. Frequentemente forma a base de um Modelo de Desenvolvimento de Aplicativo, onde diferentes blocos Funcionais são atribuídos a um tipo de desenvolvimento de aplicativo alvo.
Crítico no planejamento do portfólio de aplicativos. A duplicação e a integração geram complexidade e custo para o portfólio de TI.
BIAN, FEAF, ODF do TMForum e IndEA fornecem Modelos Funcionais.
Modelo de Integração
Um Modelo de Integração identifica os limites em seu software e o método pelo qual o limite é cruzado. Não tenha medo de especificar que o limite não pode ser cruzado ou deve ser cruzado manualmente. Muita integração fraca de aplicativos apenas oferece rigidez. Desenvolver um Modelo de Integração útil requer iteração com o trabalho de um Arquiteto de Negócios desenvolvendo um Mapa Organizacional e Modelo de informações. O Modelo de Integração, o Mapa Organizacional e o Modelo de Informação informam e restringem um ao outro.
O modelo de integração é fundamental para permitir a agilidade empresarial, gerenciar o portfólio de aplicativos e reduzir os custos de TI.
Modelo de serviço
Um Modelo de Serviço é uma versão especializada de um Modelo Funcional que reduz a Funcionalidade em uma caixa preta com interfaces conhecidas. Um bom Modelo de Serviço é inestimável para desenvolver o Modelo de Desenvolvimento de Aplicativos e validar o Destino em um Modelo de Sistema. As interfaces em seu Modelo de Serviço devem ser bem identificadas em seu Modelo de Integração.
Um bom Modelo de Serviço permitirá agilidade empresarial. Não a partir do desenvolvimento de serviços de aplicativos, mas liberando mudanças em uma parte de sua empresa de outra.
Modelo Físico
Um Modelo Físico é o portfólio de software real. Vamos descrevê-lo em termos usados por fornecedores de software comercial e seu programa de desenvolvimento de aplicativos. Você precisará associá-lo aos outros Modelos de Arquitetura de Aplicativos para fazer a transição do Destino para o mundo real.
Você usa o Modelo Físico como uma restrição nos modelos abstratos de arquitetura de aplicativos. Também constitui a base da Plano de Implementação e Migração desenvolvido através da Fase F.
Técnicas de Arquitetura de Aplicativos
Usamos um amplo conjunto de técnicas para desenvolver e comunicar nossa arquitetura de aplicativos.
- A UML é onipresente no bom desenvolvimento orientado a modelos. Quando você está trabalhando em Arquitetura para dar suporte ao Desenvolvimento de Soluções, um Modelo Funcional e um Modelo de Integração devem ser desenvolvidos seguindo as práticas UML.
- As visões 4+1 são muito úteis para identificar a implicação da Meta para diferentes comunidades. O desenvolvimento de modelos 4+1 ajuda a garantir que você considere todas as mudanças relevantes.
- As Necessidades de Informação do DODAF extraem todos os fluxos de informação necessários. Não importa se o nó é uma pessoa, uma organização ou um sistema. A informação fluirá para dentro e para fora. A maneira mais rápida de eliminar a automação é colocar etapas manuais no meio de um fluxo de informações.
Modelos de Arquitetura de Aplicação Alinhados ao Caso de Uso da Arquitetura Empresarial
O nível de pergunta que você está respondendo com sua arquitetura de aplicativo direcionará o uso de diferentes modelos de arquitetura de aplicativo. Por exemplo, Arquitetura para dar suporte ao Portfólio geralmente não desenvolverá um modelo de Cadeia de Valor. Em vez disso, uma Cadeia de Valor geralmente será uma arquitetura superior e restringir sua liberdade.
| Arquitetura para apoiar a estratégia | Arquitetura para dar suporte ao portfólio | Arquitetura para Apoio ao Projeto | Arquitetura para dar suporte à entrega de soluções | |
| Modelo de Desenvolvimento de Aplicativos | Entregável chave | Entregável chave | Arquitetura Superior | Arquitetura Superior |
| Modelo de sistema | Entregável Regular | Entregável chave | Arquitetura Superior | Arquitetura Superior |
| Modelo Funcional | Entregável Regular | Entregável chave | Entregável chave & Arquitetura Superior | Entregável chave & Arquitetura Superior |
| Modelo do produto | Entrega ocasional
O nível adequado de detalhes geralmente diminui o valor |
Entregável Regular
O nível adequado de detalhes geralmente diminui o valor |
Entregável chave | Entregável chave |
| Modelo de Integração | Entrega ocasional
O nível adequado de detalhes geralmente diminui o valor |
Entregável Regular
O nível adequado de detalhes geralmente diminui o valor |
Entregável chave | Entregável chave & Arquitetura Superior |
| Modelo de serviço | Entrega ocasional
O nível adequado de detalhes geralmente diminui o valor |
Entregável Regular | Entregável chave & Arquitetura Superior | Entregável chave & Arquitetura Superior |
Influência dos modelos de arquitetura de negócios nos modelos de arquitetura de aplicativos
| Modelo de Negócios | Modelo Operacional | Cadeia de valor | Modelo de capacidade | Modelo de processo | Modelo Funcional | Modelo de informações | Modelo de Organização | |
| Modelo de Desenvolvimento de Aplicativos | Entrada principal
Requer um sistema ou modelo funcional |
Entrada principal
Requer um sistema ou modelo funcional |
Entrada principal
Requer um sistema ou modelo funcional |
Entrada principal
Requer um sistema ou modelo funcional |
Entrada principal
Requer um sistema ou modelo funcional |
Entrada principal
Requer um sistema ou modelo funcional |
Entrada limitada | Entrada limitada |
| Modelo de sistema | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | Entrada principal | Entrada limitada | Entrada principal |
| Modelo do produto | Entrada principal | Entrada principal | Entrada principal | Entrada limitada | Entrada limitada | Entrada limitada | Entrada limitada | |
| Modelo de Integração | Entrada muito limitada | Entrada principal no projeto do núcleo
Requer um sistema ou modelo funcional |
Entrada principal no projeto do núcleo
Requer um sistema ou modelo funcional |
Melhor entrada
Um link direto é muito difícil de ver. Vale a pena fazer o trabalho. |
Entrada principal no projeto do núcleo
Requer um sistema ou modelo funcional |
Entrada limitada
Use somente se outros modelos não estiverem disponíveis |
Entrada principal no projeto do núcleo
Requer um sistema ou modelo funcional |
Entrada principal no projeto do núcleo
Requer um sistema ou modelo funcional |
| Modelo de serviço | Entrada limitada
As ligações são importantes, mas uma ligação direta é muito difícil de ver |
Entrada limitada
As ligações são importantes, mas uma ligação direta é muito difícil de ver |
Entrada limitada
As ligações são importantes, mas uma ligação direta é muito difícil de ver |
Melhor entrada
Um link direto é muito difícil de ver. Vale a pena fazer o trabalho. |
Usado como um teste de integridade | Entrada principal
Um link direto é muito difícil de ver. Vale a pena fazer o trabalho. |
Entrada principal |
Modelos de arquitetura de aplicativos para casos de uso de arquitetura corporativa
Tudo casos de uso de arquitetura corporativa são sobre mudança. Todos eles analisam os tipos de mudança e como um arquiteto empresarial ajuda os tomadores de decisão a traçar um caminho a seguir.
Considero os casos de uso da arquitetura corporativa como o tipo de mudança, o objetivo da equipe de arquitetura corporativa ou as perguntas mais frequentes.
Em todos os casos de uso de arquitetura corporativa, estamos desempenhando a mesma função. Ajudamos as partes interessadas a tomar melhores decisões e liderar iniciativas de mudança bem-sucedidas. Tudo o que muda é a questão.
| Mudança Estratégica | Mudança incremental | Melhorar custo | Melhorar a qualidade | Melhore a agilidade empresarial | Mitigação do risco tecnológico | Modernização de TI | Transformação Digital | Racionalização do portfólio de aplicativos | Integração de aquisição | |
| Modelo de Desenvolvimento de Aplicativos | Principais restrições | Diretrizes-chave | Restrições críticas | Restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | ||
| Modelo de sistema | Muito útil
Lacunas e restrições críticas |
Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | |||||
| Modelo do produto | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | |||||
| Modelo de Integração | Informando restrições | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | Lacunas e restrições críticas | |
| Modelo de serviço | Muito útil para lacunas e restrições | Muito útil para lacunas e restrições | Muito útil para lacunas e restrições | Muito útil para lacunas e restrições | Muito útil para lacunas e restrições | Muito útil para lacunas e restrições | Muito útil para lacunas e restrições |
Aplicando princípios de arquitetura corporativa à arquitetura de aplicativos
Nós identificamos 7 princípios de arquitetura que todo arquiteto corporativo deve conhecer. A tabela a seguir identificou as implicações desses Princípios de Arquitetura para a Arquitetura do Aplicativo. Ao realizar governança de arquitetura corporativa, você precisa testar sua Arquitetura de Aplicativo para garantir que ela esteja em conformidade com uma arquitetura superior. Aqui, está em conformidade com os princípios da arquitetura corporativa?
| Implicação da Arquitetura de Aplicativos | |
| Não brinque com o sucesso | Se o programa não for diferenciação ou transformação, procure eliminar a mudança. Procure evitar todas as mudanças no processo ou sistema que não sejam explicitamente justificadas por custo e resultado. |
| Foco na Excelência | Alinhar com o Modelo Operacional a Modelo de capacidade.
Aproveite o Modelo de Desenvolvimento de Aplicativos para focar os gastos na diferenciação. Aproveite o Modelo de Produto para se concentrar na entrega de Produto e Serviço. |
| Por que não um? | Aproveite o Modelo de Desenvolvimento de Aplicativos e o Modelo de Produto para identificar áreas onde a duplicação é proibida. |
| Os dados são um ativo | Garanta que o controle do modelo de dados não seja entregue de forma que diminua o valor do ativo de dados. |
| Os sistemas funcionam onde trabalhamos | Local de trabalho e interface de unidade de estilo de trabalho e modelo de aplicativo. |
| Experiência de usuário indolor | Os programas de eficiência concentram-se nos processos de negócios existentes.
Os programas de diferenciação e transformação exigem mudanças na interface do usuário e engajamento à medida que a experiência com o novo processo é desenvolvida. |
| Self-service | As atividades administrativas e a implantação do aplicativo são de alto custo quando não são de autoatendimento
UX fraco é alto custo.. |
Como o TOGAF Fase C se alinha com o Desenvolvimento Ágil?
A Arquitetura do Aplicativo fornecerá várias restrições e orientações para o desenvolvimento ágil. A orientação fundamental vem do Modelo de Desenvolvimento de Aplicativos. Ele identifica onde você não deseja o desenvolvimento ágil.
Arquitetura Corporativa e Desenvolvimento Ágil cruzará em quatro áreas. o arquitetura corporativa irá:
- defina a abordagem ágil
- orientar o backlog no sprint
- restringir escolhas dentro dos sprints
- resolver a dependência entre produtos
Sempre focamos o desenvolvimento ágil em novas atividades diferenciadoras e seguimos implacavelmente as melhores práticas estabelecidas em outros lugares. A melhor prática vem de software comercial estabelecido. Certifique-se de alinhar sua arquitetura de aplicativos à sua arquitetura de negócios e concentre-se em como você adquire sistemas.
Como a Fase C do TOGAF é habilitada com o Enterprise Agility?
A agilidade empresarial não tem nada a ver com a forma como você escreve software. A agilidade empresarial diz respeito à capacidade da sua empresa de reagir a ameaças e oportunidades inesperadas. Se você precisa escrever código, sua habilidade de responder a uma ameaça ou oportunidade está em risco.
Um arquiteto de aplicativos se concentrará no quinto aspecto do modelo de agilidade empresarial - Flexibilidade. Usamos o mesmo atributo e pontuações de Agilidade no Guia de Avaliação de Capacidade identificar os sistemas de informação que devem ser capazes de mudanças rápidas. Em seguida, arquitetamos para permitir a mudança.
Modelo de agilidade empresarial
- Alerta – Você consegue detectar oportunidades e ameaças?
- Acessibilidade – Você consegue acessar informações relevantes a tempo de responder?
- Decisividade – Você pode decidir usando as informações disponíveis?
- Rapidez – Você consegue implementar suas decisões no tempo disponível?
- Flexibilidade – O que você está fazendo para reduzir as barreiras à ação?
Qual é o objetivo do TOGAF ADM Fase C?
Dentro Fase A, você identificou um arquitetura de destino simplificada - a Visão da Arquitetura. A Visão da Arquitetura incluiu todos os domínios. Atividade na Fase C, desenvolve ainda mais os domínios de arquitetura de aplicativos e dados. O sucesso requer:
- Você aborda o problema de como a empresa atual não pode atender às preferências das partes interessadas
- Você aprende o que deve mudar para permitir que a Empresa atenda às preferências das partes interessadas? (Lacunas)
- Você tem uma compreensão suficiente do trabalho é necessário para entregar as mudanças (Pacote de Trabalho)
- Você entende a interação entre mudanças e restrições em outros domínios de arquitetura para proteger o valor esperado (Especificações de Requisitos de Arquitetura)
O resultado central da Fase C é a arquitetura de aplicativo candidata. Os arquitetos de aplicativos trabalham com outros arquitetos de domínio para entender as restrições que estão sendo colocadas na arquitetura do aplicativo e quais restrições estão sendo colocadas em outros domínios.
Lembre-se, o TOGAF ADM explora possíveis mudanças. Até que você esteja desenvolvendo o Plano de Implementação na Fase F, procure a rampa de saída mais barata. Ideias ruins não significam que você não está resolvendo o problema. Você deve descartar fraco alternativas de arquitetura. Interromper ideias ruins mais cedo economiza dinheiro e permite mudanças bem-sucedidas. No momento em que uma ideia se torna ruim, pare de repente. Mate a ideia. Comemore sua vitória! Celebre que você está permitindo uma mudança bem-sucedida!
Padrões de arquitetura de aplicativos
Nós usamos padrões de arquitetura para aumentar drasticamente a produtividade e a qualidade do desenvolvimento de nossa arquitetura. Usamos uma simplificação Modelo de padrão de arquitetura que nos leva a compreender problema previsível, abordagem padrão, e as Partes difíceis. A aplicabilidade do padrão é geralmente determinada pelo trabalho, restrições e limitações necessárias.
Exemplos de padrões de arquitetura de aplicativos
Exemplos de padrões de arquitetura de aplicativos cobrem o problema de estrutura de aplicativos, migração e como projetar aplicativos.
- Estrutura do aplicativo
- Padrão MVC (Model-View-Controller)
Problema previsível— organização do código, capacidade de manutenção e testabilidade
Abordagem—separa um aplicativo em três componentes interconectados: Modelo (dados e lógica de negócios), Visualização (interface do usuário) e Controlador (lida com a entrada do usuário e atualiza o Modelo e a Visualização de acordo)
- Padrão MVC (Model-View-Controller)
- Migração de aplicativos
- Padrão Estrangulador
Problema previsível—substituindo sistemas legados
Abordagem—substituir gradualmente ou “estrangular” um sistema legado existente, construindo novos componentes em torno dele para substituir gradativamente o sistema
- Padrão Estrangulador
- Design de aplicativos (grupo de quatro padrões de aplicativos)
Como arquitetos corporativos, usamos padrões de design como restrições à liberdade das equipes de desenvolvimento de aplicativos. (Ver Arquitetura Corporativa e Ágil - Restringir Sprints)- Padrão Singleton- garante que uma classe tenha apenas uma instância e fornece um ponto global de acesso a essa instância
Considerações Finais sobre TOGAF ADM Fase C
Arquitetos de aplicativos trabalhando com um Equipe de Arquitetura Corporativa têm um conjunto de responsabilidades mais importantes do que projetar um aplicativo. Eles precisam desenvolver as diretrizes e proteções para as pessoas arquitetarem, projetarem, implementarem e desenvolverem o portfólio de aplicativos da empresa. Em suma, o arquiteto de aplicativos corporativos é diferente de um arquiteto de soluções ou um arquiteto de aplicativos que não trabalha com uma equipe EA.
Os Arquitetos de Aplicativos que trabalham no TOGAF ADM Fase C têm uma função complexa.
- trabalhar com as partes interessadas e as PMEs para selecionar mudanças no portfólio de aplicativos que possibilitem a melhor organização futura
- trabalhar com seus pares arquitetos de domínio para explorar como as melhorias necessárias no domínio de negócios são habilitadas ou impedidas no domínio do aplicativo
- trabalhe com as partes interessadas para eliminar as alterações no portfólio de aplicativos que entregam muito pouco ou custam muito. Além disso, elimine alterações em outros domínios que geram custos inaceitáveis e mudem para o portfólio de aplicativos
Na Fase C do TOGAF ADM, um dos quatro domínios de arquitetura empresarial é desenvolvido. O TOGAF deixa muito claro que você desenvolve essa arquitetura durante o desenvolvimento dos outros domínios. As alterações em um domínio habilitarão, forçarão ou bloquearão alterações em outro domínio.
Equipes EA de alto funcionamento não usam seus arquitetos de aplicativos como designers de um único aplicativo. Essa função é necessária, mas sem uma arquitetura de aplicativo que cubra partes significativas da empresa, você não pode otimizar a empresa.
O TOGAF ADM Fase C desenvolve a arquitetura do aplicativo. A arquitetura de aplicativos é a base de todas as empresas digitais modernas. Use TOGAF Fase C para concentrar os escassos recursos de mudança na obtenção do maior valor empresarial.
