Uma arquitetura empresarial robusta utiliza as decisões já tomadas.

O Poder de E

Meu participante favorito fala sobre o poder de e. E se pudéssemos ter o S5? e O P5? E se pudéssemos ter o melhor do que já temos? e Tudo o que queremos?

Antes de tomar uma decisão, quando estou explorando... alternativas de arquitetura Eu amo o poder de e. Na arquitetura empresarial. o poder de e esmaga a mão morta de como. Toda vez que eu almejo um e Preciso eliminar os obstáculos que me impedem de ter tudo. Francamente, antes de tomar uma decisão, essa é a minha tarefa.

Adoro o desafio intelectual de descobrir o que é preciso para ter o S5. e o P5. Lado a lado, a mudança agressiva e implacável para melhor com a correspondência tranquila da qualidade dos pares e melhorias incrementais de eficiência.

Em nosso trabalho, o poder de e sempre enfrenta a realidade de se. Podemos ter e:

• se nós mudamos como
• se Transferimos o trabalho entre essas equipes funcionais.
• se inventamos a antigravidade Calças Foguete Robbie

Eu ganho o poder de e quando fazemos o decisão de arquitetura para colocar o se no roteiro de arquitetura. Então, impiedosamente Gerir cada iniciativa de mudança para alcançar resultados. o se.

Estive presente na reunião em que decidiram fazer o que fosse preciso para entregar o projeto. e, E uma pessoa de alto escalão foi encarregada de tornando-o tão.

Ideias malucas, como reconstruir o núcleo do negócio do zero para cortar o custo de transação em 90%. Ou implementar um ERP personalizado para uma divisão, enquanto simplificamos impiedosamente nosso portfólio de aplicativos. Ou implementar um aplicativo quase pronto, prestes a entrar em versão beta, na principal atividade geradora de valor da empresa. Ou usar visualizações para melhorar a percepção situacional e a comunicação.

Você poderá ter as Calças Foguete do Robbie quando seus stakeholders tomarem uma decisão firme e bem informada.

Decisões firmes e bem fundamentadas são possibilitadas por arquitetura empresarial de melhores práticas.

Tudo está no Guia do praticante TOGAF—Tabela 4 e as listas de verificação de arquitetura. A Tabela 4 indica que o arquiteto empresarial precisa saber como as prioridades e preferências das partes interessadas se ajustam em resposta ao valor, esforço e risco da mudança. listas de verificação de governança de arquitetura alvo Solicita ao ARB que confirme as partes interessadas:

• compreender o trabalho necessário para atingir o estado desejado
• Compreender a incerteza (risco) inerente à execução bem-sucedida do trabalho.
• compreender quaisquer limitações de confiança que devam ter.
• Compreender como o benefício é obtido.

Heurística de risco

As calças Robbie Rocket não são impossíveis. As organizações fazem o que parece impossível o tempo todo, quando tomam uma decisão resoluta baseada em três fatores: benefício, trabalho e incerteza.

Vamos fazer uma pausa. O aparentemente impossível pode ser realizado quando sabemos o que enfrentamos. Quando conseguimos imaginar o benefício quantificado. Quando conseguimos delinear o trabalho. Quando nos adaptamos à incerteza.

Quando conseguirmos criar as informações necessárias para uma decisão definitiva.

Usar se pergunte ao difícil troca perguntas. Os benefícios advêm de abordar as se—se fizermos todo o trabalho necessário, se superarmos todas as barreiras, Se soubermos a vitória.

Nunca se obtém nenhum benefício ao ficar parado à beira de um cânion intransponível desejando que houvesse uma ponte.

Usamos uma heurística bastante complexa para testar nosso raciocínio e garantir que estamos em terreno firme quando falamos sobre isso. e bem como o seguinte se.

Valor = Benefício/Incerteza - ((Impacto de Custo^Incerteza) + Custo Operacional^Incerteza))

A visualização de um sistema distribuído de geração e transmissão de energia pode mudar a forma como um sistema complexo de produção e distribuição de grande porte é operado.

Legal. Queríamos uma nova maneira de gerenciar 50.000 gigawatts-hora (GWh) de produção de energia elétrica. Mas isso foi há muito tempo. Na época em que telas verdes eram modernas. As operações reais usavam mostradores, interruptores e botões analógicos. Interfaces visuais eram ficção científica.

A menos que você estivesse olhando para um Macintosh. Aí tudo era diferente. Interface visual e um ambiente de desenvolvimento com pouco código.

Eu sabia o que eles queriam: a capacidade de controle de energia S55 lado a lado com a capacidade de geração de energia P31. O melhor da categoria, automatizado e ágil (S55) intrinsecamente ligado ao previsível, manual e difícil de alterar. Legal. Ficção científica, tecnologia não testada e 50.000 GWh de produção.

Quando pressionados, eles explicaram. melhorar, Consegui exatamente o que esperava com um S — capacitando as pessoas. Pensamento, consciência situacional e comunicação. Depois de refletir sobre isso, eles poderiam adicionar uma carga de treinamento menor. qualidade de operação do sistema.

Lembre-se, estou buscando uma capacidade — nós queremos a capacidade de controle de potência ser radicalmente diferente. Queremos que a capacidade de controlar a geração e a distribuição seja melhorar do que a média. Para ser melhor do que muito bom. Ser melhor. Queremos o melhor.

Saberemos quando chegarmos lá.

Eu pensei em três se.

• se podemos fazer a ponte HiperCartão lacuna no sistema de controle
• se Podemos construir uma rede AppleTalk de ampla área.
• se Podemos construir um relacionamento iterativo muito estreito entre usuário e desenvolvedor, além de um controle de lançamento distribuído, anos antes do Manifesto Ágil.

Inovação coexistindo com sistemas de controle proprietários com ciclos de vida de décadas. Sistemas de controle proprietários coexistindo com infraestrutura de geração e transmissão de energia avaliada em bilhões de dólares. Infraestrutura com horizontes de planejamento de meio século e ciclos de decisão de décadas.

Arquitetura Superior

Para onde quer que você olhe, você está cercado por arquitetura superior—decisões arquitetônicas anteriores, implementações em conformidade com a arquitetura e arquiteturas-alvo nas quais ainda estamos trabalhando. arquitetura superior que orienta e restringe nosso projeto de arquitetura atual.

Este exemplo de geração de energia é o meu ponto forte. arquitetura superior Por exemplo, ninguém reconstruiria levianamente uma infraestrutura de geração e transmissão que custaria bilhões de dólares. Não há como ser inteligente na reconstrução. e se Sobre receitas alternativas ou proposta de valor. Nós fornecemos eletricidade de forma previsível. O dia todo.

Na sala de controle, tínhamos pessoas qualificadas observando mostradores analógicos e girando botões. Quando giravam os botões, enormes turbinas começavam a girar e gigawatts de produção de energia entravam em funcionamento ou paravam. Acionar um interruptor desligava uma linha de transmissão. abastecendo uma cidade para que as equipes possam subir na torre com segurança e inspecionar a linha.

Todas essas decisões são baseadas em uma infinidade de fatores. A produção deve preceder a demanda. Aquela turbina de várias toneladas pode precisar de 10 a 15 minutos para vencer a inércia. Suas luzes não esperam. Acionar os interruptores também é importante. Você nunca quer interromper o fornecimento de energia para a cidade ou dizer à equipe que é seguro subir na torre errada.

Meu arquitetura superior Era uma paridade perfeita — igualar a entrega previsível de eletricidade de nossos concorrentes do setor, ao mesmo tempo em que buscávamos ativamente aumentar a eficiência. Isso estava atrelado a um sistema altamente manual e praticamente imutável.

Logo ao lado de uma arquitetura superior com capacidade de paridade, meu cliente queria mudar o jogo. Com um software incrível. que não existia e eles não conseguiam descrever, Meu parceiro acreditava que poderia promover um melhor raciocínio e consciência situacional. Com uma assistência inteligente, seus funcionários poderiam melhorar A eficiência da geração. Provavelmente conseguiriam economizar milhões no orçamento operacional. Tudo graças a pessoas competentes, melhor informação e comunicação.

Nesse ponto, a maioria das pessoas me pergunta o que... software bacana Fiz. Quase todo mundo fica surpreso por eu não saber. Como a maioria dos meus desenvolvimento ágil - trabalho de EA, os detalhes dos detalhes do software não eram da minha alçada. Embora eu estivesse curioso, o como ser o melhor não era meu problema de arquitetura.

Especialmente em um ambiente Agile 5 Superior, pois as mudanças seriam tão rápidas quanto a descoberta de novos problemas de informação e comunicação. Eles podiam vislumbrar oportunidades ilimitadas para se aprimorarem.

Como um arquiteto corporativo, Meu problema era criar as condições para que eles pudessem ser o melhor da categoria. Assim, eles podiam mudar à medida que aprendiam, conforme novas ameaças e oportunidades surgiam. Assim, eles podiam combinar a execução de excelência com a inevitável necessidade de adaptação. agilidade empresarial. Eu precisava entregar uma caixa grande e aberta contendo S5.

Eu ia dar a eles uma plataforma visual e de baixo código. Eles iriam experimentar, aprender e retrabalhar. Eles iriam aprimorar o HyperCard por anos.

Não é um dos meus arquitetura empresarial ifs—preencher a lacuna entre o HyperCard e o sistema de controle, a rede AppleTalk de longa distância e criar um relacionamento iterativo muito próximo entre usuário e desenvolvedor—foi escrever código.

Concluindo com base nas decisões já tomadas.

Anos depois, quando John Sherwood (SABSA) estava me ensinando sobre risco como incerteza, Então pensei sobre este projeto. De repente, vi os prós e os contras. Vi a incerteza inerente às melhores práticas modernas. TOGAF O risco é o efeito da incerteza. Nosso trabalho, todos os dias, é eliminar a incerteza.

Eu sabia que meu investidor sonhava com calças-foguete. Eles queriam, sim, refazer toda a fiação do sistema de controle. Eventualmente. Sabiam que a incerteza de refazer a fiação desse sistema anulava qualquer valor potencial. O pior cenário seria o risco de apagar as luzes ou matar um eletricista.

Este projeto destaca a viabilização do S5 por meio da arquitetura, e não por meio de... uma solução. Não conseguiríamos chegar lá com um único projeto elegante e onisciente. Observe atentamente nossa heurística. A incerteza reduz o valor e aumenta os custos exponencialmente.

Valor = Benefício/Incerteza - ((Impacto de Custo^Incerteza) + Custo Operacional^Incerteza))

Um projeto elegante e onisciente não poderia ser o caminho plausível. Cada falha da onisciência é incerteza. Cada vez que não posso ter certeza, o divisor de benefícios e o expoente de custos aumentam. O valor evapora a cada incremento de incerteza.

Use candidatos, alternativas de arquitetura e transições para eliminar a incerteza. Busque o roteiro de arquitetura valor ponto de repouso.

Encontre um lugar onde seu stakeholder esteja. pode parar e colheita valor. Sem pausa. Sem elaborar uma apresentação em PowerPoint. Pare e colha os frutos.

Nunca condicione os benefícios a um futuro promissor. Garanta algo desde o início. Além disso, analise os cálculos. A incerteza destrói ideias que, de outra forma, seriam plausíveis. Eu jamais finjo uma prova de conceito adiando a superação da incerteza. prova de conceito A incerteza é desgastante. Demonstre desde cedo como superar desafios.

Elimine a incerteza sobre se.

Então, o que era o VRP-1? Ele simplesmente eliminou a incerteza que impedia a superação do obstáculo. HiperCartão / lacuna no sistema de controle e construção de um relacionamento iterativo muito estreito entre usuário e desenvolvedor.

Antigamente, os Macintoshes tinham portas seriais. Com essas portas, um eletricista certificado pegava o sinal gerado pelo movimento de um botão giratório mecânico de um painel de controle antigo e o convertia em um sinal serial. O HyperCard conseguia ler sinais seriais. E então, fazer coisas — exibir números, sombrear imagens, o que fosse necessário. Ministramos um treinamento intensivo de HyperCard para a equipe da sala de controle. Sim, ensinamos os usuários a usar o mouse e a criar pilhas de chamadas — eliminei a divisão entre desenvolvedor e usuário usando low-code para eliminar o desenvolvedor.

Bing, bang, boom. Um experimento independente para mudar o jogo. Um lugar para as partes interessadas pararem e avaliarem. Um local, visualizações de aprendizado e procedimentos de controle. Descobrindo o que era preciso para ser melhor que o melhor.

Não era minha função faça o código. Eu não precisava me preocupar com raciocínio lógico, percepção situacional ou comunicação. Isso era responsabilidade deles. Meu trabalho era facilitar. Facilitar por meio da arquitetura.

Eles poderiam mudar o jogo. se Poderíamos visualizar os dados. Se Um software útil foi desenvolvido. Em seguida, eles abordariam o "como". Na sala de controle, eles idealizariam, de forma iterativa, um pensamento mais eficaz, maior consciência situacional e melhor comunicação, e criariam as ferramentas. Meu se eram barreiras para eles.

Ao explorar objetivos — seja uma melhoria convencional ou uma ideia maluca do Robbie Rocket Pants — precisamos ter em mente que tudo é possível. se. Nunca finja que se não existem.

Procuro por inconvenientes se. Especialmente quando meu stakeholder quer muito alguma coisa. Quero ter uma conversa difícil sobre o que é preciso para superar esse abismo.

Se não podemos, nem iremos, ponte o desfiladeiro Quero celebrar o resoluto não. A decisão resoluta de não gastar nossos escassos recursos de mudança construindo um cânion estreito e intransitável, caro.

Esta semana, quero que vocês procurem em seus trabalhos por se. O que precisa mudar Para entregar o valor esperado? Então, analise sua arquitetura superior. Onde ela o limita? Decisões anteriores que devem ser respeitadas, mesmo que restrinjam sua criatividade e liberdade. Quais fatos incômodos precisam ser abordados? Para quais mudanças você precisa pedir permissão?

Então você pode faça as contas e ajude seus stakeholders. Execute o listas de verificação de governança de arquitetura alvo. Confirme que informou as partes interessadas sobre:

• todo o trabalho necessário para atingir o estado desejado
• todas as fontes de incerteza (risco) para a implementação bem-sucedida da mudança
• como o benefício é obtido

A questão mais profunda é: você está entregando o que promete? arquitetura necessáriaMeu cliente estava buscando uma solução. Transformei a solicitação em um projeto de arquitetura que viabilizou um dispositivo S5 — o melhor da categoria e extremamente eficiente. agilidade empresarial. O benefício foi a exploração contínua de um pensamento mais apurado, da consciência situacional e da comunicação. Eles precisavam da liberdade para passar algumas décadas construindo soluções transitórias e descartáveis.

Na próxima semana, iniciaremos a transição para após a decisão de agir. Como nos comunicamos com os implementadores — donos de produto, equipes de desenvolvimento ágil, portfólios de transformação e projetos tradicionais em cascata? Como capacitamos esses stakeholders a orientar o trabalho e verificar se estão no caminho certo para gerar valor?

Como sempre, aguardo com expectativa seus comentários e sugestões.

Tenha uma ótima semana!

cumprimentos

Dave

Dave Hornford
Conexiam

PS: Os monitores monocromáticos de 9 polegadas da velha guarda superaram canetas, papel e quadros-negros com visualizações em tempo real. Hoje, recorreríamos à nuvem moderna e à inteligência artificial para fazer o mesmo — permitir que nossos stakeholders obtenham o que precisam. Guia de Planejamento Baseado em Capacidades Este artigo aborda como minha equipe utiliza técnicas básicas de arquitetura — P3 e S5 — para identificar expectativas e limitações antes de solicitarmos permissão para interferir em uma organização bem-sucedida.