Arquitetura de Produtos Digitais: A Colisão da Linha Amarela

Ilusão CDO

As fronteiras têm donos. Os produtos digitais comerciais têm defensores ferozes que os protegem. Internamente, temos ilusões. Imaginamos clientes e donos. Acreditamos que o organograma sempre nos indica a autoridade de decisão.

Proprietários de produtos comerciais ambiciosos são ótimos stakeholders. Eles receberam uma área de responsabilidade: o produto. Eles têm objetivos muito claros. Direções — expectativa, restrição, apetite ao risco. Eles conseguem avaliar o valor das mudanças e, muitas vezes, articulam requisitos muito fortes. Trabalhei com um gerente de produto digital que precisava de uma redução de custos transacionais (95%) em sua plataforma. Não se tratava de adicionar funcionalidades, nem apenas de reduzir custos. Era um corte nos custos da plataforma para se manter competitivo.

Com donos de produto assim governança de arquitetura É um sonho. Você tem um stakeholder competente e influente. Alguém que entende a autoridade que lhe foi delegada e todo o contexto dessa autoridade.

Em seguida, temos nossos produtos internos. Começamos com uma linha tênue entre o produto e os dados. Frequentemente, temos princípios que sugerem compartilhar os dados. Estamos inferindo que, como os dados existem, o A empresa é proprietária disso..

Analisamos o organograma e encontramos um Diretor de Dados (CDO) ou um Escritório de Governança de Dados. O pensamento predominante leva a pessoa a questionar e explicar tudo ao CDO. Presume-se que o CDO, magicamente, seja o dono de todos os dados. O mais prejudicial é a suposição de que qualquer trabalho para "monetizar", democratizar e criar "melhores tomadas de decisão" seja comprovadamente valioso.

Simultaneamente, no desenvolvimento, muitas vezes confundimos a simples inserção de uma API ou a execução de uma extração para despejar dados no sistema. lago de dados virtual com mudança que melhora nossa organização.

Quando nos voltamos para o "Product Owner", encontramos um analista de negócios glorificado, preso entre os tecnólogos e uma comunidade de usuários irritada. Eles chamam a comunidade de usuários de clientes — mesmo que Marty nos diga que o cliente precisa pagar e pode simplesmente desistir. Esses "Product Owners" estão ocupados gerenciando tickets no Jira. Eles não têm autoridade nenhuma. Zero compreensão de valor. Imagine-os sabendo que a viabilidade dependia de um corte nas despesas operacionais (OpEx) e, mesmo assim, implementando esse corte no programa digital.

Com donos de produto assim governança de arquitetura Está em suporte de vida. Precisamos usar todos os recursos disponíveis. governança de arquitetura conjunto de ferramentas para descobrir as restrições que envolvem o produto, os objetivos do produto e o que a organização espera da função comercial do consumidor.

Sabemos que nossa organização é uma complexa rede de interações. Navegar, Para simplificar a complexidade, nós nos apoiamos em Modelo de risco da SABSA e o conceito de arquitetura superior encontrado em TOGAF.

Tudo o que procuro é o mesmo conhecimento e as mesmas orientações que fazem com que meus dedicados gerentes de produto comerciais durmam preocupados — mercado, posicionamento, preço, concorrência.

Tudo o que procuro é alguém que consiga avaliar potencial de crescimento, potencial de queda, valor, custo e risco.

Tudo o que eu quero são os princípios básicos da boa governança: o objetivo, as expectativas de desempenho, as restrições e a tolerância ao risco.

E eu quero isso para todos os produtos digitais.

A colisão da linha amarela

Assim que estabelecermos a estrutura de governança do Produto Digital, a tensão começa.

Na maior parte do tempo, trabalhamos internamente. Você estará cercado por ideias de pessoas que não se submetem à disciplina do mercado. Pessoas que alegam estar alinhadas a qualquer estratégia, iniciativa ou declaração de liderança. Pessoas que usam esse alinhamento para justificar suas preferências ou melhorias locais.

Você conhece o argumento do alinhamento mortal. Ele se concentra em como as coisas se sustentam, sem qualquer contribuição significativa. Sabemos que o valor é composto por benefícios que justificam o esforço, especialmente considerando a incerteza associada à obtenção desses benefícios e a incerteza quanto ao custo.

Internamente, você pode esperar um foco na tecnologia. Foco em questões como a mecânica de extrair dados de um banco de dados operacional. O custo é avaliado de forma tão acessível quanto um chamado de integração feito às pressas.

Os princípios básicos da qualidade e do fluxo de dados desaparecem na pressa de fazer algo.

Sua organização está usando a linguagem do produto para dirigir de forma perigosa.

Vamos analisar dois riscos críticos relacionados a produtos de dados.

Você não pode vender o que roubou.

Todos que vendem produtos de dados vendem metodologia e procedência.

Todos.

Quando você não possui termos de uso claros que permitam a reutilização de dados, eles são roubados.

Dados roubados nunca possuem procedência e metodologia sólidas — em termos de arquitetura de dados: fonte de dados e fluxo de dados.

Os dados roubados não são "monetizados", são protegidos. Essas empresas oferecem descontos enormes porque ninguém pode usar produtos roubados no mercado convencional.

Internamente, dados roubados contaminam até mesmo um data lake virtual. Superficialmente, dados de baixa qualidade e sem metodologia parecem idênticos a dados de alta qualidade. Mas exigem constantemente mais refinamento e pós-processamento apenas para se tornarem úteis.

Eventualmente, os dados roubados criam um problema de conformidade. Geralmente, isso se deve a informações pessoais identificáveis, segredos comerciais ou questões de jurisdição. Então, você precisa gastar mais para limpar o que era simplesmente um amontoado de dados caros e sem valor.

Se você quer se divertir um pouco, observe atentamente o retorno do seu investimento em composteiras de compostagem. Como acontece com a maioria das composteiras residenciais, aposto que você vê pessoas despejando diligentemente cascas de frutas e legumes na composteira e indo à loja de jardinagem comprar fertilizante e terra.

A Restrição de Custódia

Resolvemos esses problemas com uma boa arquitetura.

Estamos começando a criar disciplinas em torno de dados de produtos. Especialmente dados onde nosso produto digital captura informações do cliente. Navegar Usamos uma propriedade do modelo para distinguir Dados sob custódia—dados que pertencem a outra organização e só podem ser usados em estrita conformidade com o contrato.

Esta propriedade é o primeiro poste da sua cerca. Esses limites restringem severamente a integração e exigem medidas de segurança.

Na semana passada, mencionei brevemente o ServiceNow. Os CIs são obviamente custódia, Eles são usados pelo aplicativo, mas o provedor do aplicativo nunca tem motivo para analisá-los. Que tal? nomes de usuário?

Sim, nomes de usuário. Em um sistema de gerenciamento de operações de TI SaaS, o cliente configura os dispositivos para inserir pessoas em fluxos de processo, habilitar aprovações e até mesmo enviar alertas ligando para o telefone pessoal do usuário. O ServiceNow pode utilizá-los?

É obviamente conveniente usá-los para acesso e licenciamento. Mas se os direitos forem restritos, você retorna imediatamente ao problema da Apple e talvez precise encontrar uma maneira de impedir que os dados vazem para fora da empresa. ambiente do cliente. Vimos que a Apple usou o bem aplicativo e arquitetura de infraestrutura focando em limites de montagem. Eles garantem a privacidade das suas memórias processando-as no seu dispositivo. Lembre-se, eles prometem que você não vai espionar nada, mesmo que isso signifique ficar feliz só desta vez.

Leve essas mesmas ideias para dentro da empresa. Quais dados pertencem ao produto digital? Que etapas de montagem são necessárias para garantir que você os processe dentro do produto, para o produto ou pelo produto?

Então, quais dados estão disponíveis? E quais dados a empresa precisa?

Um dos nossos clientes de produtos digitais possui uma estrutura de finanças corporativas bastante enxuta. Cada família de produtos é responsável pela sua própria contabilidade e gestão de custos. Os dados financeiros que chegam ao sistema corporativo são muito restritos.

Esse design aparentemente ineficiente permite que os diferentes produtos otimizem suas operações comerciais e fiscais. O CEO pode circular pelos corredores e fazer perguntas muito pertinentes. Espera-se que os responsáveis pelo P&L conheçam e otimizem seus processos. Não há espaço para desculpas. Precisamos aplicar essa mesma disciplina a todos os nossos produtos digitais.

Defesa da Arquitetura: Recomendação de Não Conformidade

Ao longo desta conversa, tenho destacado como você busca ultrapassar os limites. Tenho enfatizado que os produtos digitais são apenas um problema de governança específico.

Trate-os como um assunto, uma área de negócios. Ao mesmo tempo, trate-os como um domínio de risco ou governança. Confio que você entenda que todo titular de dados também é um... domínio de governança. Um lugar onde existem objetivos únicos, expectativas de desempenho, restrições e apetite ao risco. Um lugar onde existe uma base sólida. principais partes interessadas.

Eu não disse um único tomador de decisão, eu disse um partes interessadas sólidas e importantes. Os stakeholders sempre vivem em grupos. Há sempre interesses concorrentes, sobreposição de poderes e direções conflitantes. Se fosse simples, não precisaríamos de arquitetura empresarial.

Meus exemplos foram todos casos em que precisávamos proteger o produto digital. Casos em que usamos assembly para processar o produto internamente ou por meio do produto. Esse é um caso específico, e é preciso saber quando ele se aplica.

O outro caso também é válido quando o dono do produto — o principal stakeholder, responsável pela governança e pelo assunto em questão — é instruído a se integrar a um todo maior. Ele é orientado a usar o sistema financeiro de serviços compartilhados.

Ambos os modelos são verdadeiros. Qualquer um dos modelos pode ser a arquitetura do seu produto digital.

Quando as pessoas param de seguir a sua arquitetura otimizada para o seu negócio e sua estratégia de entrada no mercado, elas estão cruzando a Linha Amarela. Mais cedo ou mais tarde, haverá tráfego vindo na direção oposta.

Para evitar a colisão com a linha amarela, nós, os arquitetos corporativos entrar na linha de fogo.

Em termos metodológicos, nós realizamos governança de implementação e criar um Recomendação de não conformidade. Identificar o problema é fácil, mas pouco útil. Uma recomendação informa às partes interessadas o que elas precisam fazer para recuperar o valor que a meta proporcionava. Elas já sabem o que a não conformidade está causando.

Todas as situações de não conformidade se resumem a:

1. Cumprir a meta: Alterar para entregar o valor esperado da arquitetura alvo.
2. Conceder alívio temporário: Adiar a resolução do problema.
3. Alterar a arquitetura: Aceite a perda do valor original e crie uma nova expectativa de valor com um novo objetivo.

Nós estruturamos as opções para que os líderes apropriados — as partes interessadas — façam uma escolha informada. Com um simples clique, você tem a melhor organização possível e a melhor mudança possível. É um lugar muito agradável.

Concluindo a colisão da linha amarela

Frequentemente presumimos que há virtude em partes interessadas corajosas que se mantêm firmes e impondo o objetivo. Muitas vezes existe. Muitas vezes a não conformidade é uma otimização local. Ou uma equipe de projeto que economiza em algo para atingir uma meta. dia de lançamento. Ou uma equipe ágil reivindicando a vitória. Em todos esses casos, eles estão destruindo o valor que a meta entrega.

Não tenho a arrogância de achar que sou onisciente. Sei que o mundo se move e muda. Novas abordagens, novas ferramentas surgem. A soma total do poder criativo supera em muito minha capacidade individual. equipe de consultoria incrível. Mais importante ainda, a cada manhã nossa empresa é uma nova empresa em uma nova posição.

Eu crio roteiros dinâmicos Para dar aos meus stakeholders o controle necessário para conduzir o processo. Encaro cada não conformidade como uma nova oportunidade dinâmica. Quando encontramos um caminho melhor para um objetivo melhor, o abraçamos. Imediatamente. E então comemoramos! Aproveitamos toda a criatividade e genialidade disponíveis. Minha arquitetura é sustentável e está em constante crescimento. Uau!

Então, aqui está o meu desafio desta semana. Quem pode responder com autoridade sobre seus produtos digitais? Quem arca com as vantagens e desvantagens de cada escolha? Qual é o posicionamento de mercado (contexto empresarial) e as métricas de sucesso (direções) para cada produto? Quais são as limitações de arquitetura superiores desses produtos?

Use isso para saber onde está a linha amarela. E, para estender a metáfora, que tipo de linha é essa? Aquelas linhas amarelas duplas em rodovias de montanha com placas de velocidade reduzida são uma pista. Encontre as restrições que realmente importam.

Na próxima semana, na parte final desta série sobre dados e produtos digitais, vamos analisar a técnica. As ferramentas de trabalho do arquiteto. Especificamente, exploraremos dois aspectos. Primeiro, as estruturas do modelo de Documento Lógico para transpor a fronteira entre a empresa e um produto digital. Segundo, as especificações de arquitetura para traduzir os termos de uso e montagem de dados em diretrizes concretas.

Como sempre, agradeço seus comentários e sugestões.

Tenha um ótimo dia!

Cumprimentos,

Dave

Dave Hornford
Conexiam