O desenvolvimento \u00e1gil de software se destaca na constru\u00e7\u00e3o de algo que nunca tivemos antes e que n\u00e3o sabemos como construir. J\u00e1 \u00e9 bastante dif\u00edcil construir um sistema complexo com sucesso pela segunda vez. Na primeira, provavelmente n\u00e3o se conseguir\u00e1. O m\u00e9todo \u00e1gil reduz o risco durante a implementa\u00e7\u00e3o. Ele funciona em incrementos curtos. Tenta, falha, tenta novamente. E ent\u00e3o, consegue.<\/p>\n
A abordagem \u00e1gil reduz os riscos encurtando o ciclo de tentativas.<\/p>\n
O papel de um arquiteto corporativo<\/a> \u00e9 orientar as partes interessadas a encontrar um caminho a seguir quando n\u00e3o se sabe o que fazer. A arquitetura empresarial reduz os riscos durante a defini\u00e7\u00e3o de dire\u00e7\u00e3o e o planejamento. As arquiteturas empresariais olham mais al\u00e9m do que a arquitetura \u00e1gil para\u00a0 comparar mudan\u00e7as potenciais<\/a> entre dom\u00ednios de arquitetura<\/a>.<\/p>\n A arquitetura empresarial \u00e9 projetada para informar a tomada de decis\u00f5es e reduzir o custo de esfor\u00e7os de mudan\u00e7a condenados ao fracasso.<\/p>\n Juntos, a arquitetura empresarial e a metodologia \u00e1gil reduzem os riscos. A arquitetura \u00e9 usada para reduzir riscos e custos antes do in\u00edcio da implementa\u00e7\u00e3o. A metodologia \u00e1gil reduz riscos e custos ap\u00f3s o in\u00edcio da implementa\u00e7\u00e3o.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tSaiba mais sobre a certifica\u00e7\u00e3o TOGAF\n\t\t\t<\/a>\n\t Como a arquitetura empresarial e o Agile se encaixam?<\/a><\/p>\n Arquitetura Empresarial e Metodologias \u00c1geis \u2013 Definindo a Abordagem \u00c1gil<\/a><\/p>\n Arquitetura Empresarial e Metodologia \u00c1gil \u2013 Guiando o Backlog na Sprint<\/a><\/p>\n Arquitetura Empresarial e Metodologia \u00c1gil \u2013 Restringir Sprints<\/a><\/p>\n Arquitetura Empresarial e Metodologia \u00c1gil \u2013 Resolvendo Depend\u00eancias<\/a><\/p>\n Conclus\u00e3o sobre Arquitetura Empresarial e Agile<\/a><\/p>\n\t\t\t\t Arquitetura empresarial e metodologia \u00e1gil se encaixam de maneiras inesperadas. O foco do m\u00e9todo \u00e1gil est\u00e1 no presente. Os passos para criar um software de entrega vi\u00e1vel. Dessa perspectiva, a quest\u00e3o \u00e9: o que a arquitetura empresarial faz hoje? O que ela faz para acelerar a entrega de software?<\/p>\n Arquitetura empresarial e \u00e1gil n\u00e3o se encaixam dentro do sprint. Elas se encaixam fora do ciclo de desenvolvimento. Elas se encaixam quando os arquitetos empresariais e os desenvolvedores \u00e1geis realizam seus trabalhos. Equipes de Arquitetura Corporativa bem-sucedidas entregam seus resultados. caso de uso<\/a>. Eles n\u00e3o entregam mais nada. Mesmo que pudessem.<\/p>\n Temos uma arquitetura empresarial simples e um modelo de refer\u00eancia \u00e1gil. Existem quatro padr\u00f5es principais de engajamento da arquitetura empresarial:<\/p>\n Nos \u00faltimos anos trabalhando em Transforma\u00e7\u00e3o digital<\/a> iniciativas, desenvolvemos um conjunto de padr\u00f5es de engajamento.<\/p>\n\t\t\t\t <\/p>\n Primeiro, analise o seu caso de uso de arquitetura corporativa. Que orienta\u00e7\u00e3o voc\u00ea espera fornecer? A quem voc\u00ea atende? Em seguida, analise os padr\u00f5es de engajamento que abordam os desafios do seu trabalho. Inclua-os no seu engajamento.<\/p>\n Nosso modelo de padr\u00e3o de arquitetura<\/a> tem dois elementos-chave: o problema previs\u00edvel<\/em> e o abordagem<\/em> para resolver o problema. Tamb\u00e9m reunimos o peda\u00e7os duros<\/em>. Quando consideramos um padr\u00e3o, observamos o qu\u00e3o bem ele resolve o problema e quanto trabalho extra \u00e9 necess\u00e1rio para aplic\u00e1-lo com sucesso.<\/p>\n Vamos analisar os padr\u00f5es de engajamento. O problema que resolvem, a abordagem e as dificuldades.<\/p>\n Tive uma conversa divertida com a rec\u00e9m-contratada Engenheira de Confiabilidade de Sistemas. A especialista em SRE estava animada. Finalmente iniciamos pr\u00e1ticas modernas: CI\/CD e testes automatizados. Ela me perguntou o que a Equipe de Engenharia El\u00e9trica estava fazendo para ajudar.<\/p>\n N\u00e3o pude deixar de sorrir quando ela perguntou: '\u2018O que a equipe da EA est\u00e1 fazendo para ajudar?<\/em>\u2018O que ela realmente queria dizer era:\u2018O que voc\u00ea est\u00e1 fazendo para me apoiar hoje?<\/em>\u2018Hoje, em termos de desafios imediatos, nenhum. Ela estava envolvida na implementa\u00e7\u00e3o. Ela estava analisando tudo em termos de implementa\u00e7\u00e3o.<\/p>\n Ela n\u00e3o entendia como a organiza\u00e7\u00e3o estava se desenvolvendo. Ela n\u00e3o estava ciente do roteiro de portf\u00f3lio<\/a>. O roteiro tinha um ponto de transi\u00e7\u00e3o que acab\u00e1vamos de alcan\u00e7ar. T\u00ednhamos implementado cont\u00eaineres, gerenciamento de dados de teste e um conjunto de testes automatizados fraco. Ela n\u00e3o percebeu que o planejamento tradicional de cima para baixo havia criado as circunst\u00e2ncias para seu novo cargo.<\/p>\n Ela estava pensando no desenvolvimento imediato. Eu estava pensando em todo o transforma\u00e7\u00e3o digital<\/a>. Seu papel era ajudar a organiza\u00e7\u00e3o na pr\u00f3xima transi\u00e7\u00e3o. Ela estava desenvolvendo o capacidades cr\u00edticas<\/a>. Os testes automatizados forneceriam evid\u00eancias de que as restri\u00e7\u00f5es arquitet\u00f4nicas estavam sendo seguidas. Eu estava migrando de definindo a abordagem \u00e1gil<\/a>. Eu precisava de ajuda para orientar o backlog<\/a>.<\/p>\n Dez pontes e estradas de liga\u00e7\u00e3o s\u00e3o mais valiosas do que 500 meias-pontes para lugar nenhum<\/em><\/strong><\/p>\n490 construtores de pontes ficar\u00e3o descontentes Agile \u00e9 uma escolha. Tem vantagens e desvantagens. Adotar o Agile requer escolhas sobre Produto, Plataforma, estrat\u00e9gia de entrega de servi\u00e7o e pontos de transi\u00e7\u00e3o de cima para baixo.<\/p>\n Uma equipe de EA precisa da capacidade de oferecer suporte Estrat\u00e9gia<\/a> e Portf\u00f3lio<\/a> para definir a abordagem \u00e1gil.<\/em><\/strong><\/p>\n Problema previs\u00edvel<\/strong>:Quando voc\u00ea usa o Agile?<\/p>\n Produtos externos s\u00e3o mais f\u00e1ceis de implementar do que produtos internos. Em suma, existe um mercado. Internamente, o uso do Agile impulsiona o sistema interno para produtos digitais. \u00c9 necess\u00e1rio determinar a exist\u00eancia, o escopo e a abordagem de desenvolvimento dos sistemas internos.<\/p>\n Problema previs\u00edvel<\/strong>:De onde vem o produto?<\/p>\n Abordagem<\/strong>Ajustar a defini\u00e7\u00e3o de "solu\u00e7\u00f5es" usadas para preencher lacunas e os resultados dos pacotes de trabalho para alinh\u00e1-los com produtos autossuficientes. Desenvolver um portf\u00f3lio de produtos internos e um conjunto de m\u00e9tricas de valor para esses produtos. Os produtos devem aparecer no [inserir lista de produtos\/servi\u00e7os]. roteiro de arquitetura<\/a>.<\/p>\n As plataformas podem melhorar a velocidade e a sustentabilidade do desenvolvimento. No entanto, uma plataforma mal escolhida ter\u00e1 o resultado oposto. N\u00e3o cabe \u00e0 equipe \u00e1gil decidir se usa uma plataforma, muito menos qual plataforma escolher. Usamos o termo "plataforma" para abranger SAP, M365, Facebook, Pega ou at\u00e9 mesmo OpenShift Containers.<\/p>\n Arquiteturas de Refer\u00eancia<\/a>\u00a0t\u00eam um papel cr\u00edtico na defini\u00e7\u00e3o, sele\u00e7\u00e3o e governando<\/a>\u00a0o uso de plataformas.<\/p>\n Problema previs\u00edvel<\/strong>:Quando uma plataforma deve ser usada e quando o produto deve ser irrestrito?<\/p>\n Abordagem<\/strong>: M\u00faltiplas abordagens<\/p>\n Peda\u00e7os duros<\/strong>: Quest\u00e3o de suporte e sustentabilidade do produto e da plataforma.<\/p>\n Uma estrat\u00e9gia de presta\u00e7\u00e3o de servi\u00e7os refere-se \u00e0 abordagem que as organiza\u00e7\u00f5es utilizam para fornecer produtos ou servi\u00e7os. N\u00e3o \u00e9 garantido que voc\u00ea escolher\u00e1 sua abordagem atual \u2014 interna, contratual, de aumento de equipe.<\/p>\n Problema previs\u00edvel<\/strong>:Como sua organiza\u00e7\u00e3o entregar\u00e1 desenvolvimento \u00e1gil?<\/p>\n Abordagem<\/strong>: Siga as abordagens da Arquitetura para apoiar a Estrat\u00e9gia. Questione como o desenvolvimento \u00e1gil ser\u00e1 viabilizado. Use uma Modelo Operacional<\/a> para definir valor e um Mapa Organizacional<\/a> para definir como os diferentes consumidores, desenvolvedores e operadores de um produto trabalhar\u00e3o juntos.<\/p>\n O desenvolvimento \u00e1gil tem a mesma probabilidade de saber quando parar do que qualquer outra abordagem. Pontos de Descanso de Valor s\u00e3o sin\u00f4nimos de transi\u00e7\u00f5es arquitet\u00f4nicas. Usamos esse termo para destacar que o stakeholder tem uma sa\u00edda e pode parar de investir. Os stakeholders usar\u00e3o essas sa\u00eddas por v\u00e1rios motivos:<\/p>\n Problema previs\u00edvel<\/strong>: Conhecendo o Ponto de Descanso do Valor para parar ou mudar o foco<\/p>\n Abordagem<\/strong>: Utilize roteiros de arquitetura para explorar pontos alternativos de entrega de valor. Crie relat\u00f3rios sobre as atividades em dire\u00e7\u00e3o aos estados de transi\u00e7\u00e3o.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: As considera\u00e7\u00f5es incluem o valor comparativo em repouso e o valor potencial como trampolim para outras atividades. Os implementadores raramente entendem essas conversas. Eles se envolvem emocionalmente em um caminho ou ponto de repouso. Especialmente quando a exist\u00eancia do produto, ou o pr\u00f3ximo lan\u00e7amento, est\u00e1 em considera\u00e7\u00e3o. Os l\u00edderes seniores est\u00e3o sempre em busca do melhor caminho a seguir, n\u00e3o do maior retorno potencial. Eles querem o melhor caminho.<\/p>\n Explorar os pontos de repouso do valor \u00e9 o primeiro passo. Os tomadores de decis\u00e3o precisam entender as op\u00e7\u00f5es (sele\u00e7\u00e3o com base em diferentes crit\u00e9rios e adiamento de decis\u00f5es incertas). Em seguida, identificar o que \u00e9 necess\u00e1rio para chegar aos diferentes pontos de repouso do valor selecionados.<\/p>\n Melhores pr\u00e1ticas arquitetura corporativa<\/a> de Conexiam Navigate<\/a><\/p>\n\t\t\t\n\t\t\t\t\t\t\tAgende um treinamento personalizado em arquitetura corporativa para impulsionar sua equipe\n\t\t\t<\/a>\n\t Equipes \u00e1geis fortes encontram o caminho mais eficaz a seguir. Planejamento e or\u00e7amento de longo prazo existem devido \u00e0 complexidade do ecossistema. O desafio \u00e9 unir o planejamento de longo prazo \u00e0 criatividade \u00e1gil. Unir o planejamento de cima para baixo \u00e0 execu\u00e7\u00e3o de baixo para cima.<\/p>\n Eles precisam ser informados sobre as prioridades organizacionais em termos que possam ser incorporados ao gerenciamento de pend\u00eancias.<\/p>\n O Agile existe porque as pessoas mais pr\u00f3ximas da solu\u00e7\u00e3o conseguem encontrar o caminho mais eficaz. Organiza\u00e7\u00f5es bem-sucedidas priorizam e fazem trade-offs. Sem alcan\u00e7ar o futuro desejado dentro das restri\u00e7\u00f5es de tempo e recursos, nenhum trabalho deve ser iniciado.<\/p>\n Uma equipe de EA precisa da capacidade de oferecer suporte Portf\u00f3lio<\/a> e Projeto para guia de backlog no sprint<\/em><\/strong>.<\/p>\n Problema previs\u00edvel<\/strong>:Garantir que os resultados esperados, o valor, as expectativas de desempenho em cascata e as restri\u00e7\u00f5es orientem o lan\u00e7amento e o desenvolvimento do produto.<\/p>\n Parte dif\u00edcil<\/strong>: Muitos evangelistas \u00e1geis se surpreendem com o fato de as organiza\u00e7\u00f5es que adotam a metodologia \u00e1gil permanecerem profundamente comprometidas com o planejamento e o or\u00e7amento de longo prazo. Muitas vezes, precisamos superar a mitologia de que existe uma prefer\u00eancia cultural pela metodologia em cascata.<\/p>\n Problema previs\u00edvel<\/strong>: Ter um roteiro de produto abrangente, em vez de um ciclo de lan\u00e7amento de recursos.<\/p>\n Abordagem<\/strong>: Usando um t\u00e9cnica de roteiro de arquitetura<\/a> onde o produto, ou fam\u00edlia de produtos, se posiciona no lugar do Portf\u00f3lio. Garanta que os relat\u00f3rios normais de produtos incluam atividades em dire\u00e7\u00e3o aos estados de transi\u00e7\u00e3o.<\/p>\n Peda\u00e7os duros<\/strong>: Uma excelente gest\u00e3o de produtos proporcionar\u00e1 um roteiro de produto abrangente. Muitos propriet\u00e1rios de produtos de baixo para cima n\u00e3o t\u00eam experi\u00eancia em gerenciar o ciclo de vida ou a integra\u00e7\u00e3o de um conjunto de produtos integrado. A equipe de EA precisar\u00e1 preencher vagas, ou recorrer a alternativas, com base na compet\u00eancia da organiza\u00e7\u00e3o do produto.<\/p>\n Muitas equipes de arquitetura caem na armadilha da precis\u00e3o artificial ou da onisci\u00eancia imaginada. Ambas s\u00e3o maneiras sofisticadas de descrever o pensamento em cascata. Um roteiro de arquitetura cl\u00e1ssico abordar\u00e1 transi\u00e7\u00f5es, lacunas e pacotes de trabalho. Isso ser\u00e1 incompreens\u00edvel para uma equipe de produto. Mude a linguagem para a terminologia de produto e \u00e1gil. O propriet\u00e1rio do produto precisa entender as restri\u00e7\u00f5es com as quais est\u00e1 operando.<\/p>\n A elabora\u00e7\u00e3o do roteiro exige arquitetura suficiente. A \u00fanica abordagem escal\u00e1vel \u00e9 '\u2018apenas o suficiente<\/em>."O suficiente" significa priorizar a organiza\u00e7\u00e3o e evitar problemas previs\u00edveis. "O suficiente" significa n\u00e3o interferir no design do produto. Use padr\u00f5es de arquitetura que tragam resultados para todo o portf\u00f3lio. "O suficiente" significa ignorar sinergias potenciais. "O suficiente" significa focar em problemas previs\u00edveis. O valor de evitar problemas previs\u00edveis \u00e9 alto. "O suficiente" significa n\u00e3o ter medo de usar a destrui\u00e7\u00e3o criativa. Use o conceito de ciclo de vida esperado para impulsionar refatora\u00e7\u00f5es agressivas (abordagens novas e revolucion\u00e1rias).<\/p>\n O uso das t\u00e9cnicas com o propriet\u00e1rio do produto ajuda a trazer prioridades e restri\u00e7\u00f5es organizacionais para o roteiro do produto.<\/p>\n Problema previs\u00edvel<\/strong>: Usando \u00e9picos para implementar resultados e restri\u00e7\u00f5es de cima para baixo no produto.<\/p>\n Abordagem<\/strong>: Usando estados de transi\u00e7\u00e3o bem constru\u00eddos em um t\u00e9cnica de roteiro de arquitetura<\/a> onde o produto, ou fam\u00edlia de produtos, se posiciona no lugar do Portf\u00f3lio. Garanta que os relat\u00f3rios normais de produtos incluam atividades em dire\u00e7\u00e3o aos estados de transi\u00e7\u00e3o.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: Requer produtos fortemente integrados ou fortemente restritos. A \u00e1rea de foco precisa estar na integra\u00e7\u00e3o ou nos pontos de restri\u00e7\u00e3o. V\u00e1rios produtos coexistindo em um ecossistema e compartilhando dados de refer\u00eancia s\u00e3o um exemplo simples.<\/p>\n \u00c9 comum cair na armadilha do design antecipado. O foco deve estar nas \u00e1reas em que os desenvolvedores de software precisam limitar sua criatividade devido a requisitos externos ou do ecossistema. O ideal \u00e9 que isso seja feito antecipadamente, em vez de uma rea\u00e7\u00e3o \u00e0 d\u00edvida t\u00e9cnica.<\/p>\n Quando obtivemos sucesso, adotamos ativamente a linguagem de m\u00e9todos como o SaFE e estruturamos o roteiro em termos de temas estrat\u00e9gicos e pistas de arquitetura.<\/p>\n Problema previs\u00edvel<\/strong>: Garantir que os fatores cr\u00edticos de sucesso inclu\u00eddos nos estados de transi\u00e7\u00e3o e de destino orientem a prepara\u00e7\u00e3o \u00e1gil do backlog e o planejamento \u00e9pico.<\/p>\n Abordagem<\/strong>: Traduzir medidas e objetivos top-down em crit\u00e9rios consum\u00edveis para a prepara\u00e7\u00e3o \u00e1gil do backlog. Garantir que os relat\u00f3rios regulares de produtos incluam a sele\u00e7\u00e3o e a conclus\u00e3o de atividades em dire\u00e7\u00e3o ao valor declarado.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: As medidas top-down devem ser definitivas e f\u00e1ceis de avaliar. Por exemplo, a agilidade da equipe n\u00e3o pode ser exigida para desenvolver um equil\u00edbrio sutil entre tempo de lan\u00e7amento no mercado e resili\u00eancia. \u00c9 necess\u00e1ria uma terminologia inequ\u00edvoca.<\/p>\n Quaisquer mudan\u00e7as nas medidas de cima para baixo causar\u00e3o confus\u00e3o. Isso \u00e9 especialmente verdadeiro se um estado de transi\u00e7\u00e3o tiver sido alcan\u00e7ado.<\/p>\n Para produtos internos, sempre nos certificamos de ter um modelo de custo s\u00f3lido para produtos digitais antes de introduzir medidas de custo. Sem um modelo de custo, os custos operacionais e de plataforma ser\u00e3o perdidos e todos os custos ser\u00e3o justificados com base no custo de implementa\u00e7\u00e3o. Planeje ajudar o gerente de produto interno com isso. entendendo ITFM<\/a>. Por outro lado, gerentes de produtos digitais externos normalmente t\u00eam uma compreens\u00e3o muito forte de custos.<\/p>\n Problema previs\u00edvel<\/strong>: Propriet\u00e1rios de produtos que veem toda a empresa atrav\u00e9s das lentes de seu produto e de seus usu\u00e1rios diretos.<\/p>\n Abordagem<\/strong>: Documentar o produto e sua fun\u00e7\u00e3o dentro do ecossistema. Documentar as restri\u00e7\u00f5es aplic\u00e1veis ao produto. Documentar os crit\u00e9rios de avalia\u00e7\u00e3o. Garantir que os relat\u00f3rios regulares do produto incluam o progresso em dire\u00e7\u00e3o aos estados de transi\u00e7\u00e3o e atividades alinhadas com o valor da empresa.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: Propriet\u00e1rios de produtos digitais internos costumam ser um elo fraco. Desafios comuns incluem a falta de compreens\u00e3o:<\/p>\n As equipes de Arquitetura Empresarial que d\u00e3o suporte a Portf\u00f3lio e Projeto provavelmente precisar\u00e3o restringir os Product Owners que atuam de forma "ascendente". Isso requer um esfor\u00e7o deliberado e a aloca\u00e7\u00e3o de pessoal.<\/p>\n Estamos deixando de ajudar uma equipe \u00e1gil a gerenciar suas costas e partindo para o sprint. Aqui, precisamos inserir as especifica\u00e7\u00f5es de arquitetura no software. Devemos fazer isso sem interferir na criatividade e na inova\u00e7\u00e3o da equipe \u00e1gil.<\/p>\n Toda especifica\u00e7\u00e3o de arquitetura remove um grau de liberdade. Quando restringimos a liberdade, dificultamos que a equipe \u00e1gil encontre o caminho mais eficiente. Quando as restri\u00e7\u00f5es direcionam as prioridades da empresa, facilitamos a busca pelo melhor caminho.<\/p>\n Problema previs\u00edvel<\/strong>:Garantir que as decis\u00f5es durante o sprint, cr\u00edticas para o sucesso \u00e1gil, estejam cientes e sejam direcionadas pelas prioridades, prefer\u00eancias e restri\u00e7\u00f5es organizacionais.<\/p>\n Peda\u00e7os duros<\/strong>: Encontrar um equil\u00edbrio entre os requisitos da empresa e interferir na liberdade de design e abordagem necess\u00e1ria. Isso \u00e9 especialmente verdadeiro para arquitetos com experi\u00eancia em desenvolvimento. A expertise no assunto cria uma ladeira escorregadia que vai al\u00e9m das especifica\u00e7\u00f5es da empresa e entra no design. Isso leva a uma arquitetura ruim com grande impacto inicial.<\/p>\n Arquitetos corporativos que apoiam a entrega de projetos e solu\u00e7\u00f5es devem se preparar para sprints limitados. Arquitetos focados em um ecossistema ou plataforma de produto tamb\u00e9m devem se preparar para trabalhar com equipes \u00e1geis.<\/p>\n Problema previs\u00edvel<\/strong>: Garantir que o software esteja em conformidade com as especifica\u00e7\u00f5es e padr\u00f5es da arquitetura empresarial.<\/p>\n Abordagem<\/strong>: Fornecer crit\u00e9rios de aceita\u00e7\u00e3o obrigat\u00f3rios aplic\u00e1veis ao final dos \u00e9picos e antes do lan\u00e7amento. Muitas vezes usamos Padr\u00f5es de Arquitetura de Aplica\u00e7\u00e3o<\/a> e Padr\u00f5es de Arquitetura de Dados<\/a> para criar crit\u00e9rios de aceita\u00e7\u00e3o. Incluir crit\u00e9rios de aceita\u00e7\u00e3o obrigat\u00f3rios em todos os relat\u00f3rios de testes.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: Saber quando aplicar crit\u00e9rios de aceita\u00e7\u00e3o obrigat\u00f3rios. Cedo demais distorce o desenvolvimento. Tarde demais gera press\u00e3o por exce\u00e7\u00f5es de lan\u00e7amento. Isso \u00e9 especialmente verdadeiro para produtos digitais internos que n\u00e3o t\u00eam ciclos de lan\u00e7amento realmente previs\u00edveis.<\/p>\n Classificamos nossas especifica\u00e7\u00f5es de arquitetura como:<\/p>\n A maioria dos crit\u00e9rios de aceita\u00e7\u00e3o obrigat\u00f3rios precisam ser padr\u00f5es ou padr\u00f5es de arquitetura.<\/p>\n Nunca se esque\u00e7a de sair do caminho e colher a criatividade.<\/p>\n Problema previs\u00edvel<\/strong>: Entender o que \u00e9 valorizado e como o valor \u00e9 medido.<\/p>\n Abordagem<\/strong>: A arquitetura empresarial precisa ser definitiva sobre como o valor \u00e9 descrito e mensurado. Declara\u00e7\u00f5es de valor exigem fatores cr\u00edticos de sucesso (FCS) e medidas de efic\u00e1cia (ME). Garanta que as medidas de valor sejam inclu\u00eddas nos relat\u00f3rios de produto, \u00e9pico e lan\u00e7amento.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: Muitos profissionais de TI t\u00eam uma compreens\u00e3o limitada de valor. Eles usam uma abrevia\u00e7\u00e3o r\u00e1pida que expressa valor em termos de algo entregue. O valor \u00e9 evidente na entrega.<\/p>\n Em um mundo complexo, qualquer coisa entregue pode degradar valor. Um exemplo f\u00e1cil s\u00e3o os recursos voltados para usu\u00e1rios que n\u00e3o s\u00e3o clientes-alvo. Ou quando uma unidade de trabalho solicita recursos que simplificam sua atividade em detrimento do sistema.<\/p>\n Recomendamos enfaticamente as pr\u00e1ticas b\u00e1sicas de Lean e Six Sigma. Analise a defini\u00e7\u00e3o e a quantifica\u00e7\u00e3o do valor. Busque otimiza\u00e7\u00f5es locais. Os conceitos de Cliente Alvo e Proposta de Valor do Business Model Canvas s\u00e3o muito \u00fateis.<\/p>\n Em Fase E do TOGAF<\/a>, Existe uma etapa interessante. Analise o pacote de trabalho e selecione uma estrat\u00e9gia apropriada: Greenfield, Evolutiva ou Revolucion\u00e1ria. Voc\u00ea pretende preservar o m\u00e1ximo poss\u00edvel, refatorar radicalmente ou come\u00e7ar do zero?<\/p>\n Isso \u00e9 feito no planejamento de portf\u00f3lio de produtos e ecossistemas. \u00c9 uma orienta\u00e7\u00e3o cr\u00edtica e uma forte restri\u00e7\u00e3o para uma equipe \u00e1gil. Voc\u00ea os orienta a come\u00e7ar do zero (Greenfield)? Aprimorar os sistemas existentes de forma incremental (evolu\u00e7\u00e3o)? Ou realizar uma mudan\u00e7a radical que deve eliminar o atrito e os aborrecimentos com os quais temos convivido (Revolucion\u00e1rio)?<\/p>\n Problema previs\u00edvel<\/strong>: Garantir que a estrat\u00e9gia de implementa\u00e7\u00e3o seja seguida.<\/p>\n Abordagem<\/strong>: Use o roteiro do produto e os ciclos de lan\u00e7amento para impor mudan\u00e7as radicais na abordagem.<\/p>\n Bit dif\u00edcil<\/strong>: Alinhar as mudan\u00e7as top-down na arquitetura com o roteiro do produto. Isso \u00e9 mais dif\u00edcil quando as decis\u00f5es de suporte \u00e0 Estrat\u00e9gia ou ao Portf\u00f3lio exigem uma mudan\u00e7a na abordagem do produto. Tivemos que investir muito tempo tranquilizando os propriet\u00e1rios de produtos digitais e, por meio deles, suas equipes, de que o esfor\u00e7o anterior n\u00e3o foi desperdi\u00e7ado.<\/p>\n Quando um produto precisa se adaptar a um ambiente corporativo existente ou dar suporte a um ambiente corporativo em evolu\u00e7\u00e3o, as interfaces s\u00e3o essenciais. As interfaces ser\u00e3o orientadas por dados e m\u00e9todos. Em um mundo complexo, mesmo produtos emergentes n\u00e3o ter\u00e3o liberdade para que alguma estrutura de dados e interface surjam. Dados mestres, dados de refer\u00eancia e sistemas existentes restringir\u00e3o o desenvolvimento \u00e1gil.<\/p>\n Os sistemas existentes n\u00e3o v\u00e3o mudar. O investimento est\u00e1 sendo feito em novos sistemas. \u00c9 o novo sistema que precisa se adaptar. At\u00e9 mesmo o F-22 Raptor teve que se conectar a sistemas legados usando interfaces desenvolvidas na d\u00e9cada de 1970. Nem mesmo um avi\u00e3o t\u00e3o caro poderia ter seus sistemas legados remodelados.<\/p>\n Problema previs\u00edvel<\/strong>: Identificar as interfaces necess\u00e1rias e garantir que elas sejam utilizadas.<\/p>\n Abordagem<\/strong>: Concentre o trabalho de cima para baixo em interfaces e estruturas de dados compartilhadas. Alimente os requisitos por meio de ciclos \u00e9picos e de lan\u00e7amento. Use crit\u00e9rios de aceita\u00e7\u00e3o. Muitas vezes, usamos Padr\u00f5es de Arquitetura de Aplica\u00e7\u00e3o<\/a> e Padr\u00f5es de Arquitetura de Dados<\/a> para interfaces pouco espec\u00edficas. Inclua a conformidade da interface em todos os relat\u00f3rios de teste.<\/p>\n Bit dif\u00edcil<\/strong>: As interfaces s\u00e3o um dos pontos em que o planejamento de cima para baixo e com vis\u00e3o de futuro geralmente \u00e9 necess\u00e1rio. Esfor\u00e7o para garantir uma infraestrutura de API s\u00f3lida, APIs publicadas e estruturas de dados para dados mestres, dados de refer\u00eancia e registros transacionais.<\/p>\n Equipes de produto em r\u00e1pida evolu\u00e7\u00e3o frequentemente ignoram a legisla\u00e7\u00e3o multijurisdicional ou um plano de neg\u00f3cios de mercado em expans\u00e3o. Nesses casos, a equipe de Arquitetura Corporativa tem o dever de olhar para o futuro. Via de regra, nos sentimos mais confort\u00e1veis com uma refatora\u00e7\u00e3o radical do que com o planejamento futuro. Principalmente se impusermos modularidade e interfaces.<\/p>\n Equipes \u00e1geis e desenvolvimento focado em produtos digitais s\u00e3o inadequados para resolver problemas em um ecossistema ou portf\u00f3lio de produtos. O design fundamental do \u00e1gil \u00e9 que uma \u00fanica equipe decomponha os problemas e os resolva diretamente. Existem conceitos de equipe de equipes, mas eles t\u00eam dificuldade em sair do momento atual.<\/p>\n Qualquer equipe de arquitetura precisa assumir a responsabilidade pela resolu\u00e7\u00e3o de problemas entre produtos. O desenvolvimento \u00e1gil e a integra\u00e7\u00e3o moderna tornam esse servi\u00e7o essencial mais importante do que nunca.<\/p>\n Problema previs\u00edvel<\/strong>: Conflito no portf\u00f3lio de produtos digitais bloqueia o progresso de v\u00e1rios produtos.<\/p>\n Abordagem<\/strong>: Use t\u00e9cnicas de arquitetura empresarial para encontrar as mudan\u00e7as m\u00ednimas que permitam o progresso.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: O desafio mais cr\u00edtico \u00e9 o timing. Equipes criativas de desenvolvimento \u00e1gil e com melhores pr\u00e1ticas trabalhar\u00e3o para resolver o problema. Quando o problema surge, geralmente ser\u00e1 um bloqueador cr\u00edtico, com camadas de d\u00edvida t\u00e9cnica.<\/p>\n A equipe de EA precisar\u00e1 se concentrar em estados de transi\u00e7\u00e3o incrementais para permitir o progresso em todo o portf\u00f3lio de produtos.<\/p>\n Problema previs\u00edvel<\/strong>: Identificar a verdadeira parte interessada que pode fornecer dire\u00e7\u00e3o e aprova\u00e7\u00e3o em um portf\u00f3lio complexo de produtos internos.<\/p>\n Abordagem<\/strong>: Utilizar t\u00e9cnicas de arquitetura empresarial para identificar stakeholders e agentes de stakeholders, preocupa\u00e7\u00f5es e prefer\u00eancias. Utilizar t\u00e9cnicas de arquitetura empresarial de alternativas<\/a> e troca<\/a> orientar as partes interessadas na tomada de decis\u00f5es que direcionar\u00e3o o portf\u00f3lio de produtos. Garantir uma governan\u00e7a eficaz do portf\u00f3lio digital.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>Podemos esperar que as equipes de produtos digitais tenham fontes locais de autoridade e um modelo simplista de tomada de decis\u00e3o e autoridade para tomar decis\u00f5es. Al\u00e9m disso, sua comunica\u00e7\u00e3o e avalia\u00e7\u00e3o ser\u00e3o orientadas para a TI e t\u00e1ticas.<\/p>\n A equipe de Arquitetura Empresarial (EA) ter\u00e1 que trabalhar para garantir uma governan\u00e7a eficaz em todo o portf\u00f3lio digital e interagir com as estruturas de autoridade de produtos digitais. Al\u00e9m disso, as equipes de EA n\u00e3o possuem uma habilidade especial para obter o engajamento das partes interessadas. Elas t\u00eam, no entanto, a capacidade de representar as preocupa\u00e7\u00f5es das partes interessadas por meio de uma arquitetura superior.<\/p>\n Problema previs\u00edvel<\/strong>: Decis\u00f5es t\u00e1ticas otimizadas localmente n\u00e3o podem emergir como um ecossistema digital eficaz e sustent\u00e1vel.<\/p>\n Abordagem<\/strong>: Manter apenas o suficiente Arquitetura de Aplica\u00e7\u00e3o<\/a> e Arquitetura de dados<\/a>. Impulsione a prioridade organizacional nessa arquitetura. A arquitetura de aplica\u00e7\u00f5es precisa se concentrar em servi\u00e7os e interfaces compartilhados. A arquitetura de dados deve se concentrar em dados mestres, dados de refer\u00eancia e dados com classifica\u00e7\u00e3o de alta seguran\u00e7a. Exigindo descri\u00e7\u00f5es de metadados. Use Padr\u00f5es de Arquitetura que especifiquem a abordagem de ecossistemas.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>: Atravessar o portf\u00f3lio exige a supera\u00e7\u00e3o de duas realidades conflitantes. Primeiro, a abordagem \u00e1gil surgiu devido \u00e0 falha observada no design empresarial detalhado de cima para baixo. Segundo, solu\u00e7\u00f5es emergentes otimizadas localmente n\u00e3o conseguem construir sistemas complexos e eficientes sem forte press\u00e3o evolutiva e tempo para evoluir.<\/p>\n A \u00fanica abordagem escal\u00e1vel \u00e9 '\u2018apenas o suficiente<\/em>."O suficiente" significa priorizar as necessidades da organiza\u00e7\u00e3o e evitar problemas previs\u00edveis. Por exemplo, se a prioridade da sua organiza\u00e7\u00e3o \u00e9 a sustentabilidade, a arquitetura da sua aplica\u00e7\u00e3o deve priorizar a modularidade e o uso de infraestrutura de isolamento, como um gateway de API.<\/p>\n "Just enough" significa ficar fora do design do produto. Em vez disso, voc\u00ea precisa usar padr\u00f5es de arquitetura que atendam a todo o portf\u00f3lio.<\/p>\n "Apenas o suficiente" significa ignorar a potencial sinergia. \u00c9 comum que tentativas de imaginar um futuro complexo se transformem em uma farsa. Sinergia \u00e9 a coisa mais dif\u00edcil de encontrar. Todo o nosso trabalho de roteiro de arquitetura prova que, se voc\u00ea sempre paga a conta por algo, pode ser que voc\u00ea obtenha o benef\u00edcio. O valor da sinergia \u00e9 baixo quando a incerteza \u00e9 aplicada.<\/p>\n "Suficiente" significa focar em problemas previs\u00edveis. Ningu\u00e9m jamais construiu um cadastro distribu\u00eddo de clientes sem dados de refer\u00eancia. Nunca. Esse \u00e9 um problema de dados previs\u00edvel. Resolva-o logo. O valor de evitar problemas previs\u00edveis \u00e9 alto.<\/p>\n Just enough significa n\u00e3o ter medo de usar as for\u00e7as do mercado e a destrui\u00e7\u00e3o criativa. Utilizamos o conceito de ciclo de vida esperado para destacar onde, no ecossistema, esperamos buscar regularmente uma refatora\u00e7\u00e3o agressiva (abordagens greenfield e revolucion\u00e1rias).<\/p>\n Problema previs\u00edvel<\/strong>: Arquitetura suficiente significa que cada conting\u00eancia, cada restri\u00e7\u00e3o, cada conflito n\u00e3o foi descoberto antes do lan\u00e7amento.<\/p>\n Abordagem<\/strong>: Coloque as m\u00e3os nos bolsos e aguarde ser chamado durante a resolu\u00e7\u00e3o. A menos que seja chamado, aguarde para se envolver durante a revis\u00e3o do incidente e descobrir onde voc\u00ea falhou em identificar um problema previs\u00edvel, subestimou o risco ou n\u00e3o cumpriu um requisito de teste.<\/p>\n Peda\u00e7os Dif\u00edceis<\/strong>Existe um caso em que uma equipe de arquitetura pode ter uma emerg\u00eancia. Aqueles raros casos em que as implica\u00e7\u00f5es v\u00e3o al\u00e9m do produto. Se os usu\u00e1rios finais est\u00e3o contornando o defeito, n\u00e3o h\u00e1 emerg\u00eancia. Mas quando eles est\u00e3o criando vulnerabilidades e responsabilidades, a\u00ed sim, h\u00e1 uma emerg\u00eancia.<\/p>\nCompreens\u00e3o da arquitetura corporativa e do Agile<\/h2>\n
\n
![\"arquitetura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2023\/09\/AdobeStock_437654262.jpeg\" "\\"arquitetura")
\n\t\t\t\n\t\t\t\t\t\t\tEntre em contato conosco para obter nossa consultoria de arquitetura empresarial para ajud\u00e1-lo\n\t\t\t<\/a>\n\tComo a arquitetura empresarial e o Agile se encaixam?<\/h2>\n
\n
![\"Arquitetura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product-600x408.png\" "\\"Arquitetura")
\n\tComo usar esses padr\u00f5es de engajamento?<\/h2>\n
\n
Exemplo Pr\u00e1tico: Desenvolvimento \u00c1gil no Roteiro de Arquitetura Corporativa<\/strong><\/h3>\n
\n
\n<\/em><\/strong>490 construtores de pontes que pensavam que estavam a gerar valor<\/em><\/strong>\n
\n\t\t\t\n\t\t\t\t\t\t\tTreinamento personalizado em arquitetura corporativa para impulsionar sua equipe\n\t\t\t<\/a>\n\tDownloads de arquitetura corporativa e exemplos de arquitetura corporativa<\/a><\/h2>\n\t
Arquitetura Empresarial e Metodologias \u00c1geis \u2013 Definindo a Abordagem \u00c1gil<\/h2>\n
Padr\u00e3o de produto<\/h3>\n
Padr\u00e3o de plataforma<\/h3>\n
\n
\n
Padr\u00e3o de estrat\u00e9gia de presta\u00e7\u00e3o de servi\u00e7os<\/h3>\n
Padr\u00e3o de ponto de repouso de valor principal<\/h3>\n
\n
\n
\nEsta \u00e9 uma conversa sobre ROI. Conversas sobre ROI geralmente levam a mudan\u00e7as de prioridade.<\/li>\n\n
\n
V\u00e1 al\u00e9m com o processo e o m\u00e9todo de arquitetura empresarial de pr\u00e1ticas recomendadas<\/h2>\n
Arquitetura Empresarial e Metodologia \u00c1gil \u2013 Guiando o Backlog na Sprint<\/h2>\n
Roteiro para Guiar o Padr\u00e3o do Produto<\/h3>\n
\n
\n
Roteiro para Guiar o Padr\u00e3o \u00c9pico<\/h3>\n
Padr\u00e3o de Valor Empresarial<\/h3>\n
Restringir o padr\u00e3o de Product Owner "de baixo para cima"<\/h3>\n
\n
\n
![\"Arquitetura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product.png\" "\\"Compreens\u00e3o")
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tBaixe o Guia Pr\u00e1tico para o Desenvolvimento de uma Arquitetura Empresarial.\n\t\t\t<\/a>\n\tTreinamento em arquitetura empresarial e treinamento em TOGAF<\/h2>\n\t
Arquitetura Empresarial e Metodologia \u00c1gil \u2013 Restringir Sprints<\/h2>\n
\nExiste uma regra b\u00e1sica<\/strong><\/em>Nunca remova um grau de liberdade se n\u00e3o for necess\u00e1rio.
\nA liberdade para inovar e criar \u00e9 a alma do desenvolvimento \u00e1gil de software<\/em>\nExiste uma regra avan\u00e7ada<\/strong>:nunca tenha medo de dar a uma equipe \u00e1gil um problema realmente dif\u00edcil
\nInova\u00e7\u00e3o e criatividade criar\u00e3o solu\u00e7\u00f5es que voc\u00ea n\u00e3o pode imaginar<\/em>\n
\nPadr\u00e3o de Crit\u00e9rios de Aceita\u00e7\u00e3o<\/h3>\n
\n
\n
Padr\u00e3o de valor (medidas e pontos de repouso)<\/h3>\n
Greenfield, Evolu\u00e7\u00e3o ou Revolu\u00e7\u00e3o<\/a><\/h3>\n
Padr\u00e3o de interface de restri\u00e7\u00e3o<\/h3>\n
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tBaixe o Guia de Governan\u00e7a de Arquitetura Corporativa\n\t\t\t<\/a>\n\tArquitetura Empresarial e Metodologia \u00c1gil \u2013 Resolvendo Depend\u00eancias<\/h2>\n
Desbloqueie o Padr\u00e3o de Portf\u00f3lio<\/h3>\n
Identifique o padr\u00e3o real de stakeholders<\/h3>\n
Cruze o Padr\u00e3o de Portf\u00f3lio<\/h3>\n
Padr\u00e3o de impacto de libera\u00e7\u00e3o<\/h3>\n