Portanto, esta semana, vamos deixar de lado os roteiros e voltar ao combustível digital: Arquitetura de dados.
Se você se lembra do nosso série de dados do outono passado, Admito que sempre tive uma relação difícil com a Arquitetura de Dados. Ela é fundamental. Não há grandes arquitetura corporativa existe sem dados e arquitetura de segurança. No entanto, a discussão comum, seca e obscura, geralmente perde o foco nos negócios.
Nós nos apoiamos fortemente no modelo de dados corporativos da DAMA porque ele simplesmente funciona. Aquelas poucas páginas do DMBOK são ouro. Três modelos simples—Modelo de Assunto, Modelo de Área Temática (MAT), e Modelo Lógico de Dados (LDM) Fornecemos um Modelo de Dados Empresarial completo. De 8 a 20 tópicos com cerca de 20 entidades no SAM (Sistema de Gerenciamento de Ativos) significam que você tem a base para entender a governança de dados, o fluxo de dados e as necessidades de dados em 160 a 400 palavras. É isso.
Então nos deparamos com um produto digital.
Você conhece o produto digital que sua empresa oferece. Às vezes, toda a empresa é organizada em torno dele, como a ServiceNow. Outras vezes, ele está profundamente integrado, como na Apple. Fotos. Às vezes, ele fica ao lado dos serviços que sua empresa oferece.
Quando aplicamos o modelo DAMA clássico, ele apresenta dificuldades — francamente, ele falha. Um Assunto é uma atividade comercial. Comece com as atividades comerciais essenciais, como Vendendo, Envio, Faturamento, e Apoiar. Ótimo. Aqui temos clareza absoluta sobre a governança de dados essenciais. O chefe do transporte possui dados de envio. O chefe de vendas A empresa é responsável pelas vendas. Você planeja, vende, envia, emite faturas e presta suporte. Os dados fluem sequencialmente através de limites organizacionais claros.
É claro que a maioria das equipes tropeça em palavras como "cliente". Isso porque começaram com os dados, não com o negócio. Quando você começa com o assunto (atividade comercial), descobre que as palavras são... comprador, receptor, pagador e operador. Cada um com diferentes relações com a sua empresa — mapeie a relação correta, não um termo vago como " cliente E tudo fica claro.
Aqui está um panorama de dados corporativos. Incrível. A governança e o fluxo de dados saltam aos olhos. Há uma linguagem clara e compartilhada com a empresa. O "Produto" é simplesmente uma entidade que permeia seus Assuntos, incorporando relações de dados adicionais.
Então, você obtém um produto digital. Seu cliente acessa seu software e digita suas esperanças, medos e sonhos (mídias sociais). Ou gerencia seu ecossistema de TI (ServiceNow). Ou seu celular tira fotos com localização e data, e armazena a imagem em seu repositório de dados.
Como a expressão de uma esperança, o endereço IP usado pelo navegador, o endereço IP interno do cliente na área de controle interno e a localização do telefone do cliente às 23h25 de uma sexta-feira se encaixam no seu modelo de dados corporativo?
Uma bagunça emaranhada
A luta com os produtos digitais
Um produto digital é fundamentalmente diferente porque o cliente é dentro a máquina. O produto é incorporado à atividade. O cliente geralmente realiza essa atividade sem a nossa intervenção.
Pense no ServiceNow — uma plataforma de operações de TI consagrada. O cliente a utiliza para inserir seus Itens de Configuração (CIs) e seu portfólio de aplicações. Se não traçarmos a linha divisória entre produto e assunto, e não começarmos pelos Assuntos, enfrentaremos um ciclo infinito. Tampouco podemos aplicar nossos Assuntos (Atividades de Negócio) dentro do produto.
Os CIs eram fáceis. Podemos ver claramente que a ServiceNow Corporation pode ter um CI usado para operar o produto e que ele não tem nada a ver com o conteúdo do produto. O desafio são os dados que ultrapassam essa linha. Quando o cliente se envolve em nosso processo de negócios — quando o cliente cria um ID da ServiceNow usado para gerenciar chamados e fornecer acesso ao produto — esse ID passa a ser relevante para a ServiceNow. Assunto de segurança, Assunto de faturamento, Assunto: Atendimento ao Cliente.
Atravessamos o horizonte de eventos quando utilizamos dados relevantes para o produto em nossas operações. As coisas ficam muito estranhas quando se atravessa o horizonte de eventos.
Simplificando, não cruze o horizonte de eventos.
Separe explicitamente a Arquitetura de Dados do Produto da Arquitetura de Dados Corporativa. No momento em que iniciamos essa jornada, nos deparamos com o elefante na sala: Termos de Uso de Dados.
Você é o Correio ou o Facebook?
A separação dos dados do produto dos dados corporativos traz à tona a restrição fundamental: quais são os termos de uso dos dados? Usamos Termos de Uso em todos os lugares. Navegar Porque nos fornece uma restrição arquitetônica fundamental. Na época da Arquitetura Orientada a Serviços, eu usava o "teste do ônibus" para explicar os termos de uso. Um ônibus é um serviço compartilhado, com termos de uso rígidos. Um bilhete dá direito a um passageiro. Um bilhete em um ponto de ônibus dá direito a um passageiro em uma rota pré-programada. Esse bilhete, rota e ponto só são válidos em horários predefinidos.
O motorista não pergunta para onde você quer ir, quando quer chegar ou se deseja uma carona para casa. Tampouco permitirá que uma zebra use o bilhete. Termos de Uso claros.
Usamos uma comparação simples e direta em nosso serviços de consultoria. Ao criar um produto digital, Somos os Correios ou somos o Facebook?
Os Correios prestam um serviço vital: encaminhar mensagens de um remetente para um destinatário. Para isso, precisam de metadados altamente específicos — o endereço de destino, o endereço de retorno e o nível de serviço contratado. Mas eis a restrição absoluta: Eles nunca olham dentro do envelope. Sua arquitetura, sua governança e seus modelos de dados são construídos sob a premissa de que o conteúdo não é da sua conta. Se um funcionário dos Correios abre a correspondência para analisar suas cartas e vender anúncios direcionados, isso não é uma estratégia de monetização inteligente. É um crime.
Agora, o Facebook. O Facebook é exatamente o oposto. Sim, assim como os Correios, ele intermedia a comunicação. Ele rastreia metadados relevantes para operar o serviço. Mas o conteúdo de suas mensagens é o principal combustível do modelo de negócios deles. Eles abrem todas as mensagens e as analisam. Rastreiam o que o destinatário faz. Comparam remetentes e destinatários, assuntos e tudo mais. É como se estivessem vasculhando nossa gaveta de meias para monetizar conteúdo, marca, tipo e até mesmo o uso que fazemos delas. Porque os Termos de Uso permitem.
Qualquer termo de uso pode funcionar. Alguns termos de uso, como os do WhatsApp, são projetados para oferecer privacidade extrema. Outros concedem acesso a tudo. Lembre-se de que isso não é privacidade — nem mesmo o Facebook garante isso. divulgar Suas esperanças, sonhos e obsessões. Mas eles os usam. Eles os usam porque os termos do produto permitem. Quando você viola os termos de uso, você comete uma falha arquitetônica enorme. Você falhou em governar os limites.
Os Termos de Uso são sempre definidos por proprietário. Proprietário do serviço, proprietário do produto, proprietário da instalação, proprietário da área de negócios. Não importa. Pragmaticamente, buscamos o Proprietário do Produto. Não um membro qualquer de uma equipe ágil — a pessoa responsável pelo produto oferecido aos nossos clientes. A pessoa que consegue equilibrar os termos de uso aceitáveis para os clientes com os termos aceitáveis para a empresa. Lembre-se, muitos clientes de transporte público querem um motorista em tempo integral. Alguém esperando pacientemente para levá-los aonde quiserem. E esse serviço existe, a um preço diferente.
Assembleia como a principal forma de aplicação da lei
Os Termos de Uso estabelecem um limite controlável. A tensão reside em cada limite. A arquitetura prospera ao lidar com as condições de contorno.
O recurso "Memórias" do app Fotos da Apple alimenta a tensão. A Apple oferece armazenamento e compartilhamento comuns em toda a sua plataforma, o que se assemelha bastante à mediação comunitária do Facebook. No entanto, a principal proposta de valor da Apple é a privacidade. Eles defendem ferozmente seus termos de uso. Chegam ao ponto de retirar serviços do mercado quando não conseguem garantir que ninguém tenha acesso às suas informações pessoais. gaveta de meias da Apple Sem a sua participação ativa.
Internamente, eles não gastam um centavo processando dados de clientes para cumprir um mandado. Porque eles não pode olhar. Eles afirmam isso no tribunal. Não existe porta dos fundos..
Em seguida, eles oferecem um serviço que analisa e seleciona suas fotos para você — memórias. No entanto Os seus termos de utilização garantem privacidade absoluta..
Eles abordam essas rígidas limitações — a Apple não pode ver e suas fotos são selecionadas — com forte eficácia. arquitetura de aplicação. Em termos de navegação, trata-se simplesmente de usar o Modelo de montagem.
A integração de funcionalidades é uma tarefa central para um arquiteto de aplicações. Essa integração define limites de integração, ciclo de vida e dependências — é o desafio crítico da arquitetura de aplicações. Sabemos que a funcionalidade pode ser colocada em qualquer lugar. Literalmente em qualquer lugar. Você pode incorporá-la em uma aplicação corporativa, expô-la em um microsserviço ou até mesmo integrá-la diretamente em um ASIC.
Para cumprir os Termos de Uso de dados, a Apple opta deliberadamente por implementar a funcionalidade AI Worker diretamente no dispositivo de borda — seu iPhone. Ao integrar o processamento e os dados, a Apple se distancia fisicamente dos dados. Ela abandona, conscientemente, a vantagem de monetizar o cliente.
Ignore o que você declarou e as consequências negativas surgirão como abutres. A responsabilidade legal força a proteção posterior ao fato, gerando complexidade, acumulando dívida técnica e custos — além de uma caixa de responsabilidade escondida em algum canto escuro.
Quando tiver termos de uso para seu produto digital, siga as diretrizes da Apple. Crie a arquitetura do aplicativo, a arquitetura tecnológica e a arquitetura de segurança que atendam aos requisitos.
Conclusão: Corte o nó
Se você não começar com os dados do produto e não conhecer seus termos de serviço — o Facebook, que coleta informações para ganhar a vida, os Correios, que coletam informações quando instruídos a fazê-lo, ou a Apple, que não pode coletar informações — sua arquitetura inevitavelmente se desviará para a responsabilidade legal.
Os seus maiores desafios surgem quando as operações da sua empresa são aprimoradas com o uso de dados do produto. Um exemplo simples é utilizar as identidades mantidas pelos seus clientes dentro do seu produto SaaS para dar suporte ao controle de acesso ou à autorização.
Você nunca vai desatar o nó ajustando seus temas de "Vendas", "Suporte" ou "Operações de TI". Isso é como puxar a corda com mais força. Só aperta o nó. É o mesmo que marcar mais uma reunião sobre o mesmo assunto. quem é o proprietário do cliente.
Meu desafio desta semana é analisar seus Produtos Digitais. Você separa de forma clara e objetiva os Produtos Digitais na arquitetura da sua aplicação? E a sua Arquitetura de Dados? Ou você mistura tudo numa complexa teia de dados para operar? seu negócios e suporte de aplicativos seu Tem um negócio? Comece a destacar seus produtos digitais como assuntos em questão. Comece a declarar explicitamente os Termos de Uso. Comece governando sua arquitetura seguindo as instruções que lhe foram dadas.
Na próxima semana, mostrarei exatamente como resolvemos esse problema. Analisaremos como arquitetar a fronteira e estabelecer restrições claras. Começaremos simplesmente estendendo o modelo de dados corporativo DAMA padrão e tratando cada produto digital como um Sujeito DAMA.
Como sempre, agradeço seus comentários e sugestões.
Tenha um ótimo dia!
Cumprimentos,
Dave Dave Hornford Conexiam
PS. Se desvendar a complexidade da sua arquitetura de dados é uma prioridade crítica para você, dê uma olhada em nossa solução. Workshop de Fundamentos de Arquitetura de Dados. Ajudaremos você a mapear seus Sujeitos, definir seus Contratos de Dados e garantir que seus Termos de Uso estejam orientando sua arquitetura, e não a prejudicando.