Pensar como um arquiteto
Também em 28 idiomas
English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 1 de 7 do capítulo Pensar como um arquiteto de dados, o primeiro capítulo do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: a visão geral do capítulo · Próximo: O modelo de dados é o esqueleto
A pergunta que este módulo responde: Qual é a diferença entre construir e arquitetar, e o que um arquiteto realmente faz?
Durante a maior parte da minha carreira, eu fui um construtor.
Comecei como desenvolvedor. Trabalhei com Java e .NET antes de ir para o Salesforce, e passei anos projetando sistemas, escrevendo código, integrando plataformas, ensinando arquitetos e revisando arquiteturas.
Mas uma das lições mais importantes que aprendi pelo caminho é que ser um ótimo construtor e ser um ótimo arquiteto nem sempre são a mesma coisa.
Um construtor pergunta:
Como eu construo isso?
Um arquiteto precisa fazer outro conjunto de perguntas:
Devemos construir isso?
Por que estamos construindo desse jeito?
Quais são as alternativas?
O que acontece quando isso ficar maior?
O que acontece quando falhar?
E que decisão estamos tomando hoje que, daqui a três anos, vamos desejar ter pensado melhor?
Lembro de um projeto para uma empresa de varejo com agendamentos. Perguntei: quantos agendamentos por dia por loja? Depois: quantas lojas vocês têm? E quantos dias por semana vocês abrem? Rapidamente percebi que teríamos milhões de agendamentos só no primeiro ano. Essas são as perguntas que um arquiteto faz no início de um projeto.
É dessa mudança de pensamento que este curso realmente trata.
A pessoa que segura a planta
Seção intitulada “A pessoa que segura a planta ”Já usei essa analogia muitas vezes ao ensinar arquitetos.
Imagine um canteiro de obras. Há pessoas concretando, passando a parte elétrica, instalando o encanamento, levantando paredes e fazendo dezenas de outros trabalhos especializados. Elas precisam ser muito boas no que fazem.
Mas alguém também precisa estar segurando a planta.
Essa pessoa precisa entender como todas essas peças se encaixam. Precisa perceber quando algo que acontece em uma parte do projeto cria um problema em outro lugar.
Isso é arquitetura.
Em tecnologia, às vezes cometemos o erro de achar que o arquiteto é simplesmente a pessoa que sabe mais. Não é bem isso. Conhecer a plataforma importa. Você precisa de profundidade técnica. Mas arquitetura não é um concurso de perguntas e respostas.
O trabalho do arquiteto é tomar boas decisões, às vezes com informações incompletas e requisitos concorrentes, e entender as consequências dessas decisões.
Essa é uma habilidade muito diferente.
Não apenas aceite o requisito
Seção intitulada “Não apenas aceite o requisito ”Um dos primeiros hábitos que quero que os arquitetos desenvolvam é simples:
Pergunte por quê.
Alguém diz a você:
Precisamos de mais um objeto.
Por quê?
Precisamos deste campo copiado para a Conta.
Por quê?
Precisamos de todos esses dados armazenados no Salesforce.
Por quê?
Isso não significa ser difícil. Significa entender o requisito real do negócio em vez de implementar imediatamente a solução proposta.
Um requisito muitas vezes chega disfarçado de design.
“Precisamos de um novo objeto personalizado” não é necessariamente um requisito. O requisito pode ser, na verdade, “precisamos registrar esta informação separadamente”. Essas coisas não são iguais.
Depois que você entende o requisito real, pode começar a explorar alternativas. Talvez um novo objeto seja exatamente a resposta certa. Talvez a informação pertença a algum lugar que já existe. Talvez o Salesforce nem devesse ser dono desses dados.
O arquiteto precisa separar o que o negócio precisa de uma forma proposta de entregar isso.
Estávamos trabalhando em uma aplicação de vendas, e o cliente tinha várias aprovações, cada uma com um aprovador e uma data. O primeiro pedido foi adicionar Aprovador 2 e Aprovador 3, cada um com uma data, como campos na Oportunidade. Quando investigamos mais a fundo, percebemos que podiam ser mais de duas ou três. Então movemos as aprovações para um objeto filho. O pedido era por mais campos; o requisito era registrar cada aprovação, quantas fossem.
Pensar além do requisito
Seção intitulada “Pensar além do requisito ”Dois hábitos decorrem de perguntar por quê, e cada um ganha seu próprio módulo mais adiante neste capítulo.
Geralmente há mais de uma resposta. O Salesforce nos dá muitas formas de resolver um problema, e algumas delas estão erradas quase de imediato. Escolher entre as que funcionam é a arte dos trade-offs (módulo 4).
E os requisitos que lhe passam não são todos os requisitos que você tem. Ninguém diz “garanta que isso funcione quando a carga noturna der certo só pela metade”, mas isso continua sendo um requisito. Eu olho todo design por três lentes: construa para hoje, planeje para amanhã, planeje para a falha (módulo 5).
Pense em alguém que contrata um arquiteto para projetar um prédio. Essa pessoa não pede um alarme de incêndio nem um sistema de sprinklers, nem que o prédio fique em pé num terremoto. Ela espera isso como parte do trabalho, sem pedir. Nosso mundo funciona do mesmo jeito. Ninguém pede tratamento de erros elegante, logs ou uma forma de se recuperar quando algo falha. Cabe ao arquiteto saber quais desses sistemas pertencem ao design, e colocá-los lá.
Torne seu raciocínio visível
Seção intitulada “Torne seu raciocínio visível ”Um arquiteto não deve simplesmente entrar numa sala e anunciar: “É isto que vamos fazer.”
Seu trabalho também é explicar o porquê. Quero que as partes interessadas entendam as alternativas que consideramos e os trade-offs envolvidos. Isso não significa entregar a um executivo um documento de design de 40 páginas. Significa conseguir explicar a mesma arquitetura para um desenvolvedor, para a área de negócio e para um executivo: conversas diferentes sobre a mesma decisão.
E a forma de fazer isso é com plantas e instruções claras, como a pessoa que segura a planta no canteiro de obras. Para um arquiteto de dados, uma das plantas mais importantes é o modelo de dados.
Se ninguém entende por que uma decisão foi tomada, há uma boa chance de alguém acabar desfazendo-a. E essa pessoa pode ter motivos perfeitamente razoáveis, porque ninguém nunca explicou a decisão original.
O arquiteto não precisa construir tudo
Seção intitulada “O arquiteto não precisa construir tudo ”Há outra transição que pode ser difícil, especialmente para quem chega à arquitetura vindo do desenvolvimento.
Você não precisa construir tudo pessoalmente.
Eu ainda gosto de entender como as coisas funcionam em um nível bem técnico, e essa base importa. Mas, como arquiteto, sua responsabilidade fica maior do que a sua própria implementação. Você não precisa construir tudo; precisa saber dar às pessoas que constroem a direção certa e os parâmetros certos. Isso significa entender o suficiente para orientar o trabalho delas, para reconhecer quando uma implementação proposta cria um problema de arquitetura, e para transitar entre os detalhes e a visão geral.
Às vezes isso significa mergulhar fundo em uma consulta, uma API ou um modelo de dados.
Às vezes significa dar um passo atrás e perguntar se deveríamos estar fazendo qualquer parte disso.
E, cada vez mais, quem está construindo não são só pessoas. Com a IA, o arquiteto pode estar trabalhando diretamente com a ferramenta que gera os objetos, o código e as telas. Aí a direção, os parâmetros e as diretrizes vão para a IA, e dá-los bem passa a ser cada vez mais responsabilidade do arquiteto. Voltaremos a isso no módulo 7.
Isso faz parte da jornada de construtor a arquiteto.
Seu trabalho é tomar decisões
Seção intitulada “Seu trabalho é tomar decisões ”No fim das contas, arquitetura é sobre decisões.
Algumas decisões são fáceis de mudar. Outras não.
Um layout de página pode ser alterado. Um rótulo pode ser renomeado.
Mas escolha o modelo de dados fundamental errado, publique identificadores dos quais dezenas de sistemas passam a depender, ou coloque a cópia mestre de dados críticos no lugar errado, e mudar de ideia fica muito mais caro.
Essas são decisões de arquitetura. E são exatamente o tipo de decisão em que este curso se concentra.
Como arquiteto de dados, você vai decidir como a informação é estruturada, onde ela vive, como ela cresce, como ela se move, quem pode acessá-la e como o resto da empresa a entende.
A tecnologia importa.
Mas conhecer cada recurso do Salesforce não é o objetivo.
O objetivo é desenvolver o discernimento para saber qual ferramenta usar, quando usá-la, do que você está abrindo mão e o que acontece em seguida.
Isso é pensar como um arquiteto.
E agora podemos começar a pensar como um arquiteto de dados.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Se um pedido é um requisito real, ou um design proposto para ele.
- Quais perguntas fazer antes de construir qualquer coisa: devemos, por que desse jeito, o que mais poderíamos fazer, o que acontece quando crescer ou falhar.
- Quais decisões cabem ao arquiteto e quais pertencem às pessoas que constroem; e que direção e parâmetros dar a quem constrói, sejam pessoas ou IA.
- Como explicar uma decisão para que um desenvolvedor, a área de negócio e um executivo a entendam.