TOGAF ADM Fase C — Desenvolvimento da 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?
Conhecimento Essencial da Fase C
Considerações finais sobre a Fase C do TOGAF ADM - Arquitetura de aplicação
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 eficazes. 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 é o TOGAF Fase C?
A Fase C avança ainda mais no conceito de domínios de arquitetura. Esta fase desenvolve a arquitetura da aplicação e a arquitetura de dados. Formalmente, a Fase C divide o tratamento Domínio de Arquitetura de Dados e o Domínio de Arquitetura de Aplicação são individuais.
Assim como a Fase B, a Fase C se baseia na Visão da Arquitetura. Há uma diferença: a Fase C tem a obrigação adicional de viabilizar a arquitetura de negócios. Isso não significa tratar a arquitetura de negócios como requisitos, mas sim confirmar a coerência das metas resumidas em desenvolvimento.
Mudanças em um domínio geram restrições e requisitos para 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 orientarão a análise relevante para que as partes interessadas selecionem entre alternativas de arquitetura
- quais modelos de arquitetura de aplicação 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 dos candidatos em termos das preocupações das partes interessadas
- que uma arquitetura de aplicação alvo atual e candidata
- lacunas na arquitetura da aplicação
- produtos de trabalho candidatos que mudam o negócio
A Fase C concentra-se em aspectos como design do aplicativo, fluxo de dados, integração, abordagem de desenvolvimento, construção versus compra e planejamento de mudanças. A avaliação e a compreensão adequadas desta fase são essenciais.
O que é o TOGAF Fase C?
Na Fase C do TOGAF, você está criando a arquitetura do aplicativo. Arquitetos de aplicação liderar o desenvolvimento da arquitetura da sua aplicação. O decisões arquitetônicas feito na Fase C para arquitetura de aplicação interagir 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 Aplicação
- 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árias para a execução das atividades de uma empresa - Modelo de Integração
- As atividades completas que uma empresa realiza, normalmente agrupadas para mostrar como elas se relacionam entre si – Modelo de Serviço
- O que é o portfólio de software – Modelo Físico
Tenha sempre em mente que você está buscando aprimorar a organização. Aprimoramento requer mudança e gera valor. O valor e o custo da mudança podem ser mensurados. 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, lembre-se de que há muitos usos para os mesmos termos. Procure o propósito do modelo e não se deixe enganar quando o rótulo for diferente do que você o chamaria. Por exemplo, o que você chama de modelo funcional, outra pessoa chamará de serviço. Em nosso consultoria de arquitetura empresarial, sempre nos concentramos 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 Aplicação?
Uma arquitetura de aplicação é uma descrição do seu portfólio completo de software que indica quando comprar, quando usar SaaS e quando desenvolver. Ela indica onde você deve estabelecer limites entre os sistemas. Ela indica como você abordará o ciclo de vida do seu software.
Podemos garantir que a arquitetura atual do seu aplicativo não está alinhada com a arquitetura do seu negócio. Uma arquitetura de aplicativo requer uma arquitetura empresarial. O desenvolvimento da arquitetura de negócios exige que os arquitetos de aplicativos se unam e interajam com as partes interessadas.
Juntamente com as partes interessadas e o arquiteto de negócios, o arquiteto de aplicações explora como as escolhas de software viabilizam e restringem os objetivos da organização. Consideramos potenciais melhorias para entender o impacto imediato e de médio prazo. Em conjunto, potenciais mudanças que geram pouco, exigem muito trabalho ou geram muita incerteza são descartadas do roteiro de arquitetura.
Quando estamos desenvolvendo equipes de arquitetura empresarial, nós dizemos ao arquitetos corporativos dois fatos centrais sobre a Fase C do TOGAF - Arquitetura de Aplicação. Primeiro, até que você tenha uma Modelo de Desenvolvimento de Aplicação, Você não pode prosseguir. Até que você saiba como suas escolhas de aplicativos habilitam e restringem sua arquitetura de negócios, os detalhes dos seus aplicativos são inúteis. Em segundo lugar, se eles acreditarem que precisam se aprofundar na funcionalidade e integração de aplicativos, sempre desenvolverão uma arquitetura de aplicativos de baixa qualidade.
Em um moderno empresa transformada digitalmente, todos os domínios da arquitetura interagem. As escolhas em um domínio possibilitam, entregam ou bloqueiam resultados em outro domínio. A maioria dos objetivos de negócios depende de Arquitetura de TI correta. 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 atuar. Por exemplo, um arquiteto de aplicações pode não enxergar o impacto das mudanças na arquitetura de negócios. Ou pode não articular um requisito em termos que permitam ao arquiteto de segurança agir.
O papel mais importante do arquiteto corporativo é cruzar fronteiras. Sejam elas de domínio, habilidade ou autoridade, o arquiteto corporativo precisa ultrapassá-las.
Qual é o papel do Arquiteto de Aplicação na Fase C?
Na Fase C do TOGAF, esperamos que o Arquiteto de Aplicação entregue a arquitetura de domínio. Isso requer o desenvolvimento de modelos que mostrem a origem da deficiência e como superá-la. Ele conduzirá a análise de trade-off com as partes interessadas para determinar a arquitetura alvo.
O arquiteto do aplicativo precisará colaborar com os outros arquitetos de domínio.
Desconecte-se da arquitetura de negócios. Conheça e entenda a 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 Aplicação entregue a arquitetura de domínio. Isso requer o desenvolvimento de modelos que mostrem a origem da deficiência e como superá-la. Ele conduzirá a análise de trade-off com as partes interessadas para determinar a arquitetura alvo.
O arquiteto do aplicativo precisará colaborar com os outros arquitetos de domínio.
Desconecte-se da arquitetura de negócios. Conheça e entenda a Modelo Operacional e os atributos de Competência e Automação do Modelo de Capacidade.
Tenha em mente que deficiências em um domínio geralmente são resolvidas em outro, e 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 deficiências em um domínio geralmente são resolvidas em outro, e 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
Abordagens em cascata não produzem resultados. As melhores práticas de arquitetura empresarial não sã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, apenas o suficiente para testar as restrições em cascata.
A sequência clássica implícita em muitos diagramas ADM do TOGAF é a ordem em que podemos encerrar 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.
Arquitetos de aplicações desempenham um papel fundamental em uma equipe de arquitetura empresarial. Nada acontece em uma empresa digital moderna sem software. Escolhas ruins de aplicações prejudicarão...'o negócio.' Os arquitetos de aplicação 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.
Conversas do Manual de IA Agencial
Conversas sobre o Guia Prático de IA Agencial: Temos estado profundamente imersos no cenário em constante evolução da adoção de IA, embarcando numa jornada que abrange tanto as complexidades técnicas quanto a transformação digital em geral. Desenvolvemos o Guia do Líder Empresarial […]
Baixe a Arquitetura de Referência de Capacidades Críticas para Adoção de IA
Baixe a Arquitetura de Referência de Capacidades Críticas para Adoção de IA. A adoção de IA exige pensamento inovador. Atualmente, não dispomos de práticas recomendadas comprovadas para a adoção generalizada de IA que melhorem consistentemente nossas organizações. Precisamos da capacidade de reimaginar nosso […]
Download do Guia do líder empresarial para IA
Download Business Leader's Guide to Artificial Intelligence As organizações que aplicam com sucesso a tecnologia inovadora têm tido uma vantagem competitiva. A tecnologia inovadora não vem com padrões de sucesso e práticas recomendadas estabelecidas. A tecnologia inovadora é inédita e [...]
Faça o download da Introdução ao padrão TOGAF, 10ª edição
Download Introdução ao Padrão TOGAF®, 10ª edição O Padrão TOGAF, 10ª edição, facilita a adoção das práticas recomendadas de arquitetura empresarial. Ele separa os conceitos universais das melhores práticas comprovadas. O padrão destaca onde [...]
Download do Guia de Planejamento Baseado em Capacidades
Faça o download do Guia de Planejamento Baseado em Capacidades Sempre se esforce para obter valor. Metade de uma melhoria é um desperdício de 100%! Ninguém ensina uma águia a engatinhar, andar ou correr. As águias voam! Faça o download de Teach your Eagles to Fly: Planejamento baseado em capacidades [...]
Faça o download do Guia de Avaliação de Capacidade de Arquitetura de Negócios
Faça o download do Guia de Avaliação de Capacidade da Arquitetura de Negócios Faça o download do Guia de Avaliação de Capacidade da Arquitetura de Negócios. O planejamento baseado em capacidade é uma das técnicas mais poderosas de aprimoramento da arquitetura de negócios. A prática recomendada de planejamento baseado em capacidade usa a capacidade como uma gestão [...]
Faça o download da amostra de princípios de arquitetura corporativa
Download de exemplos de princípios de arquitetura Faça o download de um exemplo de princípios de arquitetura corporativa. Os princípios da arquitetura corporativa identificam como abordar um problema ou uma decisão. A abordagem sempre o direciona para suas prioridades duradouras. Faça o download da amostra de princípios de arquitetura corporativa [...]
Faça o download do Guia de Governança da Arquitetura Corporativa
Faça o download do Guia de Governança da Arquitetura Corporativa Faça o download do 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. Faça o download do Guia de Governança da Arquitetura Corporativa [...]
Download da integração do TOGAF e do SABSA
Faça o download da integração do TOGAF e do SABSA Reúna o SABSA, a melhor estrutura de arquitetura de segurança do mundo, e o TOGAF, a estrutura de arquitetura corporativa padrão do setor. Faça o download da integração do TOGAF e do SABSA Integração do TOGAF e do SABSA Inclui O SABSA usa um [...]
Faça o download da arquitetura de referência do recurso de arquitetura corporativa
Download Enterprise Architecture Capability Reference Architecture A Enterprise Architecture Capability Reference Architecture acelerará o estabelecimento e o aprimoramento da sua equipe de EA. Projete sua Equipe de Arquitetura Empresarial para o sucesso. Identifique e aprimore a arquitetura de sua empresa [...]
Conhecimento Essencial da Fase C
Todas as Fases do TOGAF ADM levam você a desenvolver o conhecimento necessário. O resultado da Fase C é a arquitetura da aplicação candidata, incluída na arquitetura dos sistemas de informação candidatos.
| Saída e resultado | Conhecimento Essencial |
| O arquitetura de domínio de arquitetura de aplicação aprovado 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 que são 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 o desenvolvimento de arquitetura
Fase C Bare Bones
Na Fase C, podemos simplificar o trabalho de um arquiteto de aplicações para determinar como uma empresa deve melhorar. Isso requer entender em que ela está tentando ser boa, onde está aquém do melhor e o que precisa mudar para que ela seja a melhor.
Os princípios básicos da Fase C são:
- Saber como o portfólio de aplicações permite capturar valor
Toda organização possui uma cadeia de valor. Atividade que transforma um insumo 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 fornecem manutenção de registros.
Você deve otimizar seu software para a função de criação de valor ou manutenção de registros. Assuma a manutenção de registros. Não confunda a importante função da manutenção de registros com a criação de valor.
Conhecer a origem do custo e da complexidade
Cada portfólio de aplicações gera custos e complexidade. Pensamos em software como um mecanismo complexo que foi montado ao longo do tempo. Conectamos tudo a tudo. Com produtos digitais, 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 corporativas, 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 ver uma situação proativamente e reagir. O software faz exatamente o que lhe é dito. O software só faz o que lhe é dito.
O fluxo de informações acontece em torno do software para que a tarefa certa seja realizada. Esse tipo de fluxo de informações prejudica a agilidade da empresa. Ele prejudica 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. Aproveitamos os conceitos e atributos em modelos de capacidade para orientar as escolhas sobre a arquitetura da nossa aplicação. 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. Todos eles criam e produzem informações. Você precisa saber o que são, as informações que consomem e quem os executa.
- O que precisa mudar para entregar o melhor portfólio de aplicativos?
Desenvolvemos arquitetura de aplicativos para aprimorar uma organização. A maioria das mudanças não faz diferença substancial. A maioria das mudanças ocorre em pequenas mudanças. Concentre seu tempo em mudanças substanciais que impulsionem agilidade empresarial significativa, custos ou criação de valor.
Os três elementos essenciais para a conclusão da Fase C:
- Primeiro, O que precisa mudar? Mudança de foco, design organizacional, requalificação, terceirização, internalização, automação. Tudo isso são mudanças. Fazemos isso para melhorar uma organização.
- Segundo, quando deve ser alterado? Existem dependências? E quanto às pré-condições? Você está alterando o cenário para uma alteração posterior?
- Terceiro, Como você saberá se a mudança foi bem-sucedida? Qual é o seu teste de governança para determinar o sucesso? Como você protegerá o valor?
As partes interessadas na arquitetura empresarial são responsáveis por todas as decisões sobre o que deve ser alterado e quando. O arquiteto de aplicações é responsável por descrever os testes de governança para permitir que as partes interessadas direcionem o projeto de mudança, o segundo e o terceiro resultados.
Treinamento em arquitetura empresarial e treinamento em TOGAF
Treinamento personalizado em arquitetura corporativa
Treinamento personalizado em arquitetura corporativa O treinamento personalizado em arquitetura corporativa aborda o desenvolvimento profissional de que sua equipe de EA precisa. Os bons arquitetos corporativos usam um amplo conjunto de habilidades e métodos, além do conhecimento especializado no domínio, para desenvolver [...]
Curso de treinamento em arquitetura de negócios
Treinamento em Arquitetura Empresarial A arquitetura empresarial eficaz depende da arquitetura empresarial. O curso oferece aos alunos as habilidades e o conhecimento para desenvolver a arquitetura de negócios em um ambiente de arquitetura corporativa. A arquitetura de negócios envolve a descrição da estrutura da empresa [...]
Educação on-line eficaz
Educação on-line eficaz A educação on-line 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 desviar a atenção do tópico principal. Distância eficaz [...]
Curso de Treinamento Avolution ABACUS
Treinamento do Avolution ABACUS A arquitetura empresarial eficaz depende de modelagem e análise formais. Oferecemos o treinamento do Avolution ABACUS com arquitetos corporativos práticos. Os alunos adquirem habilidades e conhecimentos para criar arquiteturas empresariais e de domínio integradas neste [...]
Curso de treinamento em arquitetura empresarial TOGAF
Você quer treinamento para a certificação TOGAF? Demonstre seu conhecimento de arquitetura empresarial com a Certificação TOGAF Curso de treinamento em arquitetura empresarial TOGAF® Dê um passo importante para ser um arquiteto empresarial melhor com o Padrão TOGAF, 10º [...]
Início do trabalho do arquiteto corporativo
Kickstart do arquiteto corporativo Precisamos manter nossas habilidades atualizadas. Agora mais do que nunca. Use o Kickstart de Arquitetura Empresarial para melhorar sua capacidade de oferecer uma arquitetura empresarial transformadora. Este pontapé inicial de 90 dias é como a Conexiam Consulting [...]
Entregas da Arquitetura do Aplicativo TOGAF ADM Fase C
Um resultado central da Fase C é a arquitetura do aplicativo. Esta é uma parte da arquitetura empresarial completa.
Entregas de arquitetura de aplicativos da Fase C do TOGAF e casos de uso de arquitetura empresarial
Existem quatro propósitos principais para o desenvolvimento da arquitetura empresarial. Os diferentes resultados da Fase C do TOGAF têm importância diferente em cada propósito.
| Arquitetura para dar suporte à estratégia | Arquitetura para dar suporte ao portfólio | Arquitetura de Apoio ao Projeto | Arquitetura para dar suporte à entrega de soluções | |
| Produto de trabalho da fase C: Arquitetura da aplicação do candidato | Entrega principal
O uso principal é a compreensão das partes interessadas sobre a meta e o trabalho. O uso secundário é a criação de Especificação de Requisitos de Arquitetura para Arquitetos |
Entrega principal
O uso principal é a compreensão das partes interessadas sobre a meta e o trabalho. O uso secundário é a criação de Especificação de Requisitos de Arquitetura para Arquitetos |
Antes do início do projeto e da finalização do caso de negócios
O uso principal é a criação de Especificação de Requisitos de Arquitetura para Implementadores |
Antes da contratação de parceiros de execução (incluindo provedores internos)
O uso principal é a criação de Especificação de Requisitos de Arquitetura para Implementadores |
| Produto de trabalho da fase C: itens do roteiro do candidato | Entrega principal
O uso principal é a compreensão do trabalho pelas partes interessadas. O uso secundário é a criação de restrições para os arquitetos |
Entrega principal
O uso principal é a compreensão do trabalho e da dependência pelas partes interessadas. O uso secundário é a criação de restrições para os arquitetos |
Uso limitado Pode ser usado como entrada para projetos com múltiplas mudanças interativas |
Antes da contratação de parceiros de execução (incluindo provedores internos).
O uso principal é a identificação da mudança necessária e das preferências de como executá-la, para gerenciar a seleção e o engajamento do parceiro de entrega da solução |
| Produto de Trabalho da Fase C: Especificação de Requisitos de Arquitetura | Uso limitado
Geralmente, os arquitetos podem inferir restrições a partir da arquitetura superior. |
Uso limitado
Geralmente, os arquitetos podem inferir restrições a partir da arquitetura superior. |
Entrega principal
Antes da conclusão do início do projeto |
Entrega principal
Antes do engajamento e da contratação |
Tabela 3 Guia da série TOGAF: Guia do arquiteto corporativo para o desenvolvimento de arquitetura
Arquitetura de Aplicação de Candidatos
Existem quatro propósitos principais para o desenvolvimento da arquitetura empresarial. Modelos diferentes têm importâncias diferentes para cada propósito.
Componentes do Roteiro de Arquitetura da Aplicação de Candidatos
O que precisa 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 como tudo o que é necessário para viabilizar essa mudança.
Frequentemente usamos um Modelo de Sistema para resumir a mudança. O Modelo de Sistema permite abstração suficiente do software real para termos uma conversa sobre planejamento e execução. Geralmente usamos pontuações e pacotes de trabalho para articular uma mudança. Para mais informações sobre o uso de pontuações, consulte o Guia de avaliação de capacidade de arquitetura de negócios.
Utilizamos todos os componentes do Architecture Roadmap em TOGAF Fase E - Roteiro de Arquitetura.
Especificação de Requisitos de Arquitetura de Aplicação de Candidatos
Defina como você avaliará a mudança. Como a melhoria será avaliada?
Frequentemente usamos pontuações em nossos modelos para descrever 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 designs e implementações.
Vá além com o processo e o método de arquitetura empresarial de práticas recomendadas
Melhores práticas arquitetura corporativa de Conexiam Navigate
Desenvolvimento de uma visão de arquitetura
Desenvolvimento de uma visão da arquitetura A arquitetura corporativa é uma bússola essencial. Ela ajuda as organizações a navegar pelas complexidades da tecnologia, da estratégia e das operações. O núcleo da arquitetura corporativa é uma abordagem sistemática. O objetivo é garantir [...]
Como definir os princípios da arquitetura corporativa
Como Definir os Princípios da Arquitetura Empresarial Para definir os Princípios da Arquitetura Empresarial, comece entendendo o que é um princípio e como aplicá-lo. Assim, podemos desenvolver princípios arquitetônicos sólidos que ajudem a aprimorar nossa organização. […]
Desenvolvimento da estratégia de arquitetura corporativa
Desenvolvimento da estratégia de arquitetura corporativa: Plano estratégico para mudança A estratégia de arquitetura corporativa é ação. A ação que sua organização realizará e as mudanças que fará para atingir suas metas estratégicas. O desenvolvimento da estratégia tem tudo a ver com escolha. [...]
Uso da análise de cenários para a arquitetura corporativa
Uso da análise de cenários para a arquitetura corporativa Um cenário é simplesmente um futuro plausível. A análise de cenários examina como chegamos a um futuro plausível e como os diferentes cenários afetam nossas escolhas atuais. Os cenários ajudam os líderes [...]
Práticas recomendadas para implementar ferramentas de gerenciamento de arquitetura corporativa
Melhores práticas para implementar ferramentas de gerenciamento de arquitetura corporativa As ferramentas de gerenciamento de arquitetura corporativa são projetadas para apoiar o planejamento, o projeto, a análise e a execução da arquitetura corporativa. Elas permitem que os arquitetos corporativos examinem a necessidade de mudança [...]
Desbloqueando o potencial de sua empresa: como criar um mapa de recursos eficaz
Desbloqueando o potencial de sua empresa: como criar um mapa de recursos eficaz Você está tendo dificuldades para identificar os recursos necessários para levar sua empresa ao próximo nível? Você acha difícil alinhar os recursos [...]
Tudo o que você precisa saber sobre o uso de alternativas de arquitetura
Tudo o que você precisa saber sobre o uso de alternativas de arquitetura As alternativas de arquitetura são necessárias para o bom desenvolvimento da arquitetura corporativa. Quando você inicia o desenvolvimento da arquitetura, sua empresa tem deficiências. Há áreas que precisam ser melhoradas. Você precisa [...]
Gerenciamento do trabalho de arquitetura corporativa
Gerenciamento do trabalho de arquitetura corporativa O gerenciamento do trabalho de arquitetura corporativa é fundamental para o sucesso diário de uma equipe de arquitetura corporativa. Os arquitetos devem fornecer orientações úteis antes que as partes interessadas tomem decisões informadas. Os arquitetos corporativos precisam traduzir o [...]
Como garantir o alinhamento e a responsabilidade: O papel crucial das listas de verificação de governança da arquitetura corporativa
Como garantir o alinhamento e a responsabilidade: O papel crucial das listas de verificação de governança da arquitetura corporativa As listas de verificação de governança da arquitetura corporativa simplificam os processos de governança da arquitetura corporativa. O processo de governança precisa aprovar a arquitetura de destino e fornecer governança de implementação. Uma empresa robusta [...]
Compreensão da arquitetura corporativa e do Agile
Entendendo a arquitetura corporativa e o Agile Tanto o Agile quanto a arquitetura corporativa são projetados para reduzir os riscos. O desenvolvimento ágil de software é excelente para criar algo que nunca tivemos antes e que não sabemos como criar. [...]
Modelos, ferramentas e técnicas de arquitetura de aplicativos
A Fase C do TOGAF ADM fornece a Arquitetura de Sistemas de Informação. Esta fase visa desenvolver a arquitetura de aplicação e a arquitetura de dados que compõem os sistemas de informação. No TOGAF, a primeira etapa é determinar as visões e os modelos necessários.
As preocupações das partes interessadas identificarão as visões. Existem sete modelos centrais de arquitetura de aplicativos.
- Modelo de Desenvolvimento de Aplicação que descreve o método aceitável pelo qual um sistema será desenvolvido
- Modelo de sistema que captura os grandes sistemas em torno dos quais seu portfólio de aplicativos foi projetado
- Modelo funcional que descreve tudo o que você precisa que seu portfólio de software execute
- Modelo de produto que identifica a funcionalidade usada 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 que você garanta que cada serviço tenha a agilidade, a 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 Aplicação
- 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árias para a execução das atividades de uma empresa - Modelo de Integração
- As atividades completas que uma empresa realiza, normalmente agrupadas para mostrar como elas se relacionam entre si – Modelo de Serviço
- O que é o portfólio de software – Modelo Físico
Tenha sempre em mente que você está buscando aprimorar a organização. Aprimoramento requer mudança e gera valor. O valor e o custo da mudança podem ser mensurados. 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, lembre-se de que há muitos usos para os mesmos termos. Procure o propósito do modelo e não se deixe enganar quando o rótulo for diferente do que você o chamaria. Por exemplo, o que você chama de modelo funcional, outra pessoa chamará de serviço. Em nosso consultoria de arquitetura empresarial, sempre nos concentramos 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 Aplicação
Nós usamos Padrões de arquitetura para aumentar drasticamente a produtividade e a qualidade do nosso desenvolvimento arquitetônico. Modelo de Padrão de Arquitetura nos leva a compreender a problema previsível, abordagem de padrões, e o Pedaços Difíceis. O sucesso com o padrão requer abordar o Pedaços Difíceis (trabalho necessário, restrições e limitações).
Exemplos de padrões de arquitetura de aplicativos
Os padrões de arquitetura de aplicativos de exemplo abrangem o problema da estrutura dos aplicativos, migração e como projetar aplicativos.
- Estrutura da Aplicação
- Padrão MVC (Model-View-Controller)
Problema previsível—organização do código, manutenibilidade 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 o sistema de forma incremental
- Padrão Estrangulador
- Design de Aplicação (Padrões de Aplicação Gang of Four)
Como arquitetos corporativos, usamos padrões de design como restrições à liberdade das equipes de desenvolvimento de aplicativos. (Veja Arquitetura Corporativa e Agile - Sprints de Restrição)- 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 Aplicação
O desenvolvimento de uma arquitetura de aplicação exigirá o desenvolvimento de vários modelos de arquitetura empresarial. Cada um explica o portfólio de software da empresa de forma diferente. A Arquitetura de Aplicação da Fase C do TOGAF se concentra no desenvolvimento da Arquitetura Alvo por meio desses modelos. Garantir que o arquiteto da aplicação alvo trabalhe com os outros domínios para possibilitar a melhor melhoria para sua empresa.
Em conjunto, os modelos descrevem a arquitetura do aplicativo. Na arquitetura corporativa completa, esses modelos se vincularão a outros modelos que descrevem os demais domínios da arquitetura corporativa.
Modelo de Desenvolvimento de Aplicação
O Modelo de Desenvolvimento de Aplicações 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.
Mais adequado para atividades comerciais administrativas que indiretamente apoiem atividades geradoras de valor. As rígidas restrições de software geram restrições à atividade comercial e ajudam a forçar a adoção de práticas padrão do setor.
- As características dos pacotes corporativos incluem múltiplos modelos funcionais sobrepostos, com modelo de dados definido. Interfaces e funcionalidades podem ser configuradas ou personalizadas. Personalizações invariavelmente geram 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, são projetados em torno de uma única abordagem para a atividade empresarial. Geralmente, possuem um modelo de dados único e bem definido. Interfaces e funcionalidades podem ser configuradas. A personalização pode ser possível. Personalizações invariavelmente geram 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 legados da sua organização. Invariavelmente projetado para suportar o modelo de comunicação existente da sua organização. Foco e otimização funcional para a atividade especializada. Espere um modelo de dados mal definido. Interfaces e funcionalidades devem ser personalizadas. O gerenciamento do ciclo de vida geralmente é ignorado e acarreta um alto custo contínuo.
Melhor utilizado para atividades empresariais na cadeia de valor primária. A flexibilidade permite a otimização da geração de valor. O uso eficaz requer a compreensão da geração de valor hoje e no futuro.
Modelo de Desenvolvimento de Aplicação
O Modelo de Desenvolvimento de Aplicações 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.
Mais adequado para atividades comerciais administrativas que indiretamente apoiem atividades geradoras de valor. As rígidas restrições de software geram restrições à atividade comercial e ajudam a forçar a adoção de práticas padrão do setor.
- As características dos pacotes corporativos incluem múltiplos modelos funcionais sobrepostos, com modelo de dados definido. Interfaces e funcionalidades podem ser configuradas ou personalizadas. Personalizações invariavelmente geram 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, são projetados em torno de uma única abordagem para a atividade empresarial. Geralmente, possuem um modelo de dados único e bem definido. Interfaces e funcionalidades podem ser configuradas. A personalização pode ser possível. Personalizações invariavelmente geram 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 legados da sua organização. Invariavelmente projetado para suportar o modelo de comunicação existente da sua organização. Foco e otimização funcional para a atividade especializada. Espere um modelo de dados mal definido. Interfaces e funcionalidades devem ser personalizadas. O gerenciamento do ciclo de vida geralmente é ignorado e acarreta um alto custo contínuo.
Melhor utilizado para atividades empresariais na cadeia de valor primária. A flexibilidade permite a otimização da geração de valor. O uso eficaz requer a compreensão da geração de valor hoje e no futuro.
Modelo de Sistema
O modelo de 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 nela. O design do seu modelo de sistema se alinhará à forma como sua empresa opera.
Assim como o modelo de capacidade do arquiteto de negócios, um modelo de sistema permite direcionar o pensamento para um sistema. Você pode analisar a melhoria de um sistema completo e, em seguida, concentrar as mudanças necessárias em tudo o que o compõe 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 é executado em termos comparáveis.
Um bom Modelo de Produto formará a base de um arquitetura de referência para seus produtos. Você precisa especificar funções que sejam essenciais para o valor, o uso e a 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 mudança quando as funções são associadas aos seus Produtos e Serviços.
Modelo Funcional
O modelo funcional decompõe seu portfólio de software em funcionalidades. Ele identifica tudo o que seu software precisa fazer. Bons modelos funcionais oferecem ampla cobertura.
Assim como o modelo de processo do arquiteto de negócios, um modelo funcional costuma ser uma arquitetura de referência. É poderoso quando se busca duplicação e integração. Frequentemente, forma a base de um Modelo de Desenvolvimento de Aplicações, no qual diferentes blocos funcionais são atribuídos a um tipo de desenvolvimento de aplicação alvo.
Essencial no planejamento do portfólio de aplicações. Duplicação e integração aumentam a complexidade e o custo do 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 do seu software e o método pelo qual eles são ultrapassados. Não tenha medo de especificar que o limite não pode ser ultrapassado ou deve ser ultrapassado manualmente. Muitas integrações de aplicativos fracas só geram rigidez. Desenvolver um Modelo de Integração útil requer interação com o trabalho de um Arquiteto de Negócios, desenvolvendo um Mapa Organizacional e Modelo de Informação. 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 é essencial para permitir agilidade empresarial, gerenciar o portfólio de aplicativos e reduzir custos de TI.
Modelo de Serviço
Um Modelo de Serviço é uma versão especializada de um Modelo Funcional que reduz a Funcionalidade a uma caixa preta com interfaces conhecidas. Um bom Modelo de Serviço é inestimável no desenvolvimento do Modelo de Desenvolvimento de Aplicações e na validação do Alvo em um Modelo de Sistema. As interfaces do seu Modelo de Serviço devem estar bem identificadas no seu Modelo de Integração.
Um bom Modelo de Serviço permitirá agilidade empresarial. Não a partir do desenvolvimento de serviços de aplicação, mas ao liberar mudanças em uma parte da sua empresa a partir 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 pelo seu programa de desenvolvimento de aplicações. Você precisará associá-lo aos outros Modelos de Arquitetura de Aplicação para fazer a transição do Alvo para o mundo real.
Você usa o Modelo Físico como uma restrição aos modelos de arquitetura de aplicativos abstratos. Ele também forma a base do Plano de Implementação e Migração desenvolvido através da Fase F.
Técnicas de Arquitetura de Aplicação
Usamos um amplo conjunto de técnicas para desenvolver e comunicar nossa arquitetura de aplicativos.
- A UML é onipresente no desenvolvimento orientado a modelos. Ao trabalhar 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 da UML.
- As Visões 4+1 são muito úteis para identificar as implicações da Meta para diferentes comunidades. Desenvolver modelos 4+1 ajuda a garantir que você esteja considerando todas as mudanças relevantes.
- As Linhas de Necessidade 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. As informações fluem para dentro e para fora. A maneira mais rápida de eliminar a automação é inserir etapas manuais no meio de um fluxo de informação.
Modelos de Arquitetura de Aplicação Alinhados ao Caso de Uso da Arquitetura Corporativa
O nível de questionamento que você está respondendo com a arquitetura do seu aplicativo determinará o uso de diferentes modelos de arquitetura de aplicativo. Por exemplo, a 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 dar suporte à estratégia | Arquitetura para dar suporte ao portfólio | Arquitetura de Apoio ao Projeto | Arquitetura para dar suporte à entrega de soluções | |
| Modelo de Desenvolvimento de Aplicação | Entrega principal | Entrega principal | Arquitetura Superior | Arquitetura Superior |
| Modelo de Sistema | Entrega regular | Entrega principal | Arquitetura Superior | Arquitetura Superior |
| Modelo Funcional | Entrega regular | Entrega principal | Entrega principal & Arquitetura Superior | Entrega principal & Arquitetura Superior |
| Modelo do produto | Entregável ocasional
O nível adequado de detalhes muitas vezes diminui o valor |
Entrega regular
O nível adequado de detalhes muitas vezes diminui o valor |
Entrega principal | Entrega principal |
| Modelo de Integração | Entregável ocasional
O nível adequado de detalhes muitas vezes diminui o valor |
Entrega regular
O nível adequado de detalhes muitas vezes diminui o valor |
Entrega principal | Entrega principal & Arquitetura Superior |
| Modelo de Serviço | Entregável ocasional
O nível adequado de detalhes muitas vezes diminui o valor |
Entrega regular | Entrega principal & Arquitetura Superior | Entrega principal & 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ção | Modelo de Organização | |
| Modelo de Desenvolvimento de Aplicação | 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 | Contribuição importante no design do núcleo
Requer um Sistema ou Modelo Funcional |
Contribuição importante no design do núcleo
Requer um Sistema ou Modelo Funcional |
Melhor entrada
É muito difícil encontrar uma ligação direta. Vale a pena o esforço. |
Contribuição importante no design do núcleo
Requer um Sistema ou Modelo Funcional |
Entrada limitada
Use somente se outros modelos não estiverem disponíveis |
Contribuição importante no design do núcleo
Requer um Sistema ou Modelo Funcional |
Contribuição importante no design 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
É muito difícil encontrar uma ligação direta. Vale a pena o esforço. |
Usado como um teste de completude | Entrada principal
É muito difícil encontrar uma ligação direta. Vale a pena o esforço. |
Entrada principal |
Modelos de Arquitetura de Aplicativos para Casos de Uso de Arquitetura Corporativa
Todos casos de uso de arquitetura empresarial são sobre mudança. Todos eles analisam os tipos de mudança e como uma arquiteto corporativo ajuda os tomadores de decisão a traçar um caminho a seguir.
Considero os casos de uso da arquitetura empresarial como o tipo de mudança, o propósito da equipe de arquitetura empresarial ou as perguntas mais frequentes.
Em todos os casos de uso de arquitetura empresarial, desempenhamos a mesma função. Auxiliamos as partes interessadas a tomar melhores decisões e lideramos iniciativas de mudança bem-sucedidas. A única coisa que muda é a pergunta.
| Mudança estratégica | Mudança incremental | Melhore os custos | Melhorar a qualidade | Melhore a agilidade empresarial | Mitigando o Risco Tecnológico | Modernização de TI | Transformação digital | Racionalização do Portfólio de Aplicações | Integração de Aquisição | |
| Modelo de Desenvolvimento de Aplicação | Principais restrições | Diretrizes principais | 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 os princípios da arquitetura empresarial à 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 da Aplicação. Ao executar governança de arquitetura empresarial, você precisa testar a Arquitetura do seu Aplicativo para garantir que ela esteja em conformidade com a arquitetura superior. Nesse caso, ela está em conformidade com os princípios da arquitetura corporativa?
| Implicações da Arquitetura da Aplicação | |
| Não brinque com o sucesso | Se o programa não for diferenciação ou transformação, procure eliminar mudanças. Procure evitar qualquer mudança em processos ou sistemas que não seja explicitamente justificada em termos de custo e resultado. |
| Foco na Excelência | Alinhar com o Modelo Operacional o Modelo de Capacidade.
Aproveite o modelo de desenvolvimento de aplicativos para concentrar os gastos na diferenciação. Aproveite o Modelo de Produto para focar 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. |
| Dados são um ativo | Garanta que o controle do modelo de dados não seja perdido de maneiras que diminuam o valor do ativo de dados. |
| Os sistemas funcionam onde trabalhamos | O local de trabalho e o estilo de trabalho determinam a interface e o modelo de aplicação. |
| Experiência do usuário sem complicações | Programas de eficiência se concentram nos processos de negócios existentes.
Programas de diferenciação e transformação exigem mudanças na interface do usuário e no engajamento à medida que a experiência com novos processos é desenvolvida. |
| Self-service | As atividades administrativas e de implantação de aplicativos têm alto custo quando não são de autoatendimento
UX fraco tem alto custo. |
Como a Fase C do TOGAF se alinha ao Desenvolvimento Ágil?
A Arquitetura da Aplicação fornecerá diversas restrições e orientações para o desenvolvimento ágil. A orientação fundamental vem do Modelo de Desenvolvimento de Aplicações. Ele identifica onde você não deseja desenvolvimento ágil.
Arquitetura Empresarial e Desenvolvimento Ágil se cruzarão em quatro áreas. O a arquitetura empresarial irá:
- definir a abordagem ágil
- orientar o backlog no sprint
- restringir escolhas dentro dos sprints
- resolver a dependência do produto cruzado
Sempre focamos o desenvolvimento ágil em atividades inovadoras e diferenciadoras e seguimos rigorosamente as melhores práticas estabelecidas em outros lugares. As melhores práticas vêm de softwares comerciais consolidados. Certifique-se de alinhar a arquitetura da sua aplicação à arquitetura do seu negócio e concentre-se em como você adquire sistemas.
Como o TOGAF Fase C habilita com agilidade empresarial?
A agilidade empresarial não tem nada a ver com a forma como você escreve software. Agilidade empresarial diz respeito à capacidade da sua empresa de reagir a ameaças e oportunidades inesperadas. Se você precisa escrever código, sua capacidade de responder a uma ameaça ou oportunidade está em risco.
Um arquiteto de aplicação 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 Capacidades para identificar os sistemas de informação que devem ser capazes de mudanças rápidas. Em seguida, arquitetamos para possibilitar 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?
- Determinação – Você consegue 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 da Fase C do TOGAF ADM?
Em Fase A, você identificou um arquitetura de destino simplificada - a Visão da Arquitetura. A Visão da Arquitetura incluiu todos os domínios. A atividade na Fase C desenvolve ainda mais os domínios da arquitetura de Aplicação e Dados. O sucesso requer:
- Você aborda o problema de como a empresa atual não consegue 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 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 do aplicativo candidato. Arquitetos de aplicativos trabalham com outros arquitetos de domínio para entender as restrições impostas à arquitetura do aplicativo e quais restrições estão sendo impostas a outros domínios.
Lembre-se de que o ADM do TOGAF explora mudanças potenciais. Até que você esteja desenvolvendo o Plano de Implementação na Fase F, procure a saída mais barata. Ideias ruins não significam que você não está resolvendo o problema. Você deve descartar ideias fracas alternativas de arquitetura. Interromper ideias ruins mais cedo economiza dinheiro e possibilita mudanças bem-sucedidas. No momento em que uma ideia se torna ruim, pare imediatamente. Mate a ideia. Comemore sua vitória! Comemore o fato de você estar possibilitando uma mudança bem-sucedida!
Padrões de Arquitetura de Aplicação
Nós usamos Padrões de arquitetura para aumentar drasticamente a produtividade e a qualidade do nosso desenvolvimento arquitetônico. Utilizamos um modelo simplificado Modelo de Padrão de Arquitetura que nos leva a compreender a problema previsível, abordagem de padrões, e o Pedaços Difíceis. A aplicabilidade do padrão geralmente é determinada pelo trabalho necessário, restrições e limitações.
Exemplos de padrões de arquitetura de aplicativos
Os padrões de arquitetura de aplicativos de exemplo abrangem o problema da estrutura dos aplicativos, migração e como projetar aplicativos.
- Estrutura da Aplicação
- Padrão MVC (Model-View-Controller)
Problema previsível—organização do código, manutenibilidade 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 o sistema de forma incremental
- Padrão Estrangulador
- Design de Aplicação (Padrões de Aplicação Gang of Four)
Como arquitetos corporativos, usamos padrões de design como restrições à liberdade das equipes de desenvolvimento de aplicativos. (Veja Arquitetura Corporativa e Agile - Sprints de Restrição)- 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 a Fase C do TOGAF ADM
Arquitetos de aplicação 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 os parâmetros para que as pessoas arquitetem, projetem, implementem e desenvolvam o portfólio de aplicativos da empresa. Em suma, O arquiteto de aplicativos corporativos é diferente de um arquiteto de soluções ou de um arquiteto de aplicativos que não trabalha com uma equipe EA.
Arquitetos de aplicativos que trabalham na Fase C do TOGAF ADM têm uma função complexa.
- trabalhar com as partes interessadas e as PMEs para selecionar mudanças no portfólio de aplicativos que permitam a melhor organização futura
- trabalhar com seus pares arquitetos de domínio explorar como as melhorias necessárias no domínio do negócio são ativadas ou evitadas no domínio da aplicação
- Trabalhar com as partes interessadas para eliminar mudanças no portfólio de aplicativos que ofereçam pouco ou custem muito. Além disso, eliminar mudanças em outros domínios que gerem custos e mudanças inaceitáveis no portfólio de aplicativos.
Na Fase C do TOGAF ADM, um dos quatro pilares fundamentais domínios de arquitetura empresarial é desenvolvido. O TOGAF deixa bem claro que você desenvolve essa arquitetura durante o desenvolvimento dos outros domínios. Alterações em um domínio permitirão, forçarão ou bloquearão alterações em outro domínio.
Equipes de EA de alto desempenho não utilizam seus arquitetos de aplicações como designers de uma única aplicação. Essa função é necessária, mas sem uma arquitetura de aplicação que cubra partes significativas da empresa, não é possível otimizá-la.
A Fase C do TOGAF ADM desenvolve a arquitetura do aplicativo. A arquitetura do aplicativo é a base de todas as empresas digitais modernas. Use a Fase C do TOGAF para concentrar recursos escassos de mudança na obtenção do máximo valor empresarial.
