Pensar como um arquiteto
Também em 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 sustenta-se 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 programador. Trabalhei com Java e .NET antes de ir para o Salesforce, e passei anos a projetar sistemas, a escrever código, a integrar plataformas, a ensinar arquitetos e a rever 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 é que eu construo isto?
Um arquiteto precisa de fazer outro conjunto de perguntas:
Devemos construir isto?
Porque é que estamos a construir desta forma?
Quais são as alternativas?
O que acontece quando isto ficar maior?
O que acontece quando falhar?
E que decisão estamos a tomar hoje que, daqui a três anos, vamos desejar ter pensado melhor?
Lembro-me de um projeto para uma empresa de retalho com marcações. Perguntei: quantas marcações por dia por loja? Depois: quantas lojas têm? E quantos dias por semana abrem? Rapidamente percebi que teríamos milhões de marcações só no primeiro ano. Estas são as perguntas que um arquiteto faz no início de um projeto.
É desta 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 esta analogia muitas vezes ao ensinar arquitetos.
Imagine um estaleiro de obras. Há pessoas a betonar, a tratar da parte elétrica, a instalar a canalização, a levantar paredes e a fazer dezenas de outros trabalhos especializados. Precisam de ser muito boas no que fazem.
Mas alguém também precisa de estar a segurar a planta.
Essa pessoa precisa de entender como todas estas peças encaixam. Precisa de perceber quando algo que acontece numa parte do projeto cria um problema noutro lugar.
Isto é 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. É preciso 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 competência 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-lhe:
Precisamos de mais um objeto.
Porquê?
Precisamos deste campo copiado para a Conta.
Porquê?
Precisamos de todos esses dados armazenados no Salesforce.
Porquê?
Isto 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 de registar esta informação separadamente». Estas coisas não são iguais.
Depois de entender 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 destes dados.
O arquiteto precisa de separar o que o negócio precisa de uma forma proposta de o entregar.
Estávamos a trabalhar numa 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 investigámos 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 registar cada aprovação, quantas fossem.
Pensar além do requisito
Seção intitulada “Pensar além do requisito ”Dois hábitos decorrem de perguntar porquê, e cada um ganha o seu próprio módulo mais adiante neste capítulo.
Geralmente há mais de uma resposta. O Salesforce dá-nos 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 tem. Ninguém diz «garanta que isto funciona quando a carga noturna só correr bem a metade», mas isso continua a ser um requisito. Eu olho para cada design através de três lentes: construa para hoje, planeie para amanhã, planeie para a falha (módulo 5).
Pense em alguém que contrata um arquiteto para projetar um edifício. Essa pessoa não pede um alarme de incêndio nem um sistema de sprinklers, nem que o edifício fique de pé num terramoto. Espera isso como parte do trabalho, sem pedir. O nosso mundo funciona da mesma forma. Ninguém pede tratamento de erros elegante, logs ou uma forma de recuperar quando algo falha. Cabe ao arquiteto saber quais destes sistemas pertencem ao design, e colocá-los lá.
Torne o seu raciocínio visível
Seção intitulada “Torne o seu raciocínio visível ”Um arquiteto não deve simplesmente entrar numa sala e anunciar: «É isto que vamos fazer.»
O seu trabalho também é explicar o porquê. Quero que as partes interessadas entendam as alternativas que considerámos 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 a um programador, à área de negócio e a um executivo: conversas diferentes sobre a mesma decisão.
E a forma de o fazer é com plantas e instruções claras, como a pessoa que segura a planta no estaleiro de obras. Para um arquiteto de dados, uma das plantas mais importantes é o modelo de dados.
Se ninguém entende porque é que uma decisão foi tomada, há uma boa probabilidade de alguém acabar por desfazê-la. 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.
Não precisa de construir tudo pessoalmente.
Eu ainda gosto de entender como as coisas funcionam a um nível bem técnico, e essa base importa. Mas, como arquiteto, a sua responsabilidade fica maior do que a sua própria implementação. Não precisa de construir tudo; precisa de 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 a fundo numa consulta, numa API ou num modelo de dados.
Às vezes significa dar um passo atrás e perguntar se deveríamos estar a fazer qualquer parte disto.
E, cada vez mais, quem está a construir não são só pessoas. Com a IA, o arquiteto pode estar a trabalhar diretamente com a ferramenta que gera os objetos, o código e os ecrãs. 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.
Isto faz parte da jornada de construtor a arquiteto.
O seu trabalho é tomar decisões
Seção intitulada “O 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 ideias fica muito mais caro.
Estas 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, vai decidir como a informação é estruturada, onde vive, como cresce, como se move, quem lhe pode aceder 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 que ferramenta usar, quando usá-la, de que está a abdicar e o que acontece a seguir.
Isto é 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.
- Que perguntas fazer antes de construir seja o que for: devemos, porquê desta forma, 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 programador, a área de negócio e um executivo a entendam.