Pensar como un arquitecto
También en 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)
Módulo 1 de 7 del capítulo Pensar como un arquitecto de datos, el primer capítulo del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: la presentación del capítulo · Siguiente: El modelo de datos es el esqueleto
La pregunta que responde este módulo: ¿Cuál es la diferencia entre construir y hacer arquitectura, y qué hace realmente un arquitecto?
Durante la mayor parte de mi carrera he sido un constructor.
Empecé como desarrollador. Trabajé en Java y .NET antes de pasar a Salesforce, y he pasado años diseñando sistemas, escribiendo código, integrando plataformas, enseñando a arquitectos y revisando arquitecturas.
Pero una de las lecciones más importantes que aprendí en el camino es que ser un gran constructor y ser un gran arquitecto no siempre es lo mismo.
Un constructor pregunta:
¿Cómo construyo esto?
Un arquitecto tiene que hacerse otras preguntas:
¿Deberíamos construir esto?
¿Por qué lo construimos de esta manera?
¿Cuáles son las alternativas?
¿Qué pasa cuando esto crezca?
¿Qué pasa cuando falle?
¿Y qué decisión estamos tomando hoy que, dentro de tres años, desearemos haber pensado mejor?
Recuerdo un proyecto para un negocio minorista con citas. Pregunté: ¿cuántas citas al día por tienda? Luego: ¿cuántas tiendas tienen? ¿Y cuántos días a la semana abren? Enseguida me di cuenta de que íbamos a tener millones de citas solo en el primer año. Esas son las preguntas que hace un arquitecto al inicio de un proyecto.
Ese cambio de mentalidad es de lo que trata realmente este curso.
La persona que sostiene el plano
Sección titulada «La persona que sostiene el plano »He usado esta analogía muchas veces al enseñar a arquitectos.
Imagina una obra en construcción. Hay gente vertiendo concreto, tendiendo la instalación eléctrica, instalando la plomería, levantando muros y haciendo decenas de otros trabajos especializados. Necesitan ser muy buenos en lo que hacen.
Pero alguien también tiene que sostener el plano.
Esa persona necesita entender cómo encajan todas esas piezas. Necesita darse cuenta cuando algo que ocurre en una parte del proyecto crea un problema en otra.
Eso es arquitectura.
En tecnología, a veces cometemos el error de pensar que el arquitecto es simplemente quien más sabe. No es exactamente eso. Conocer la plataforma importa. Necesitas profundidad técnica. Pero la arquitectura no es un concurso de preguntas y respuestas.
El trabajo del arquitecto es tomar buenas decisiones, a veces con información incompleta y requisitos que compiten entre sí, y entender las consecuencias de esas decisiones.
Esa es una habilidad muy distinta.
No te limites a aceptar el requisito
Sección titulada «No te limites a aceptar el requisito »Uno de los primeros hábitos que quiero que desarrollen los arquitectos es sencillo:
Pregunta por qué.
Alguien te dice:
Necesitamos otro objeto.
¿Por qué?
Necesitamos copiar este campo en la cuenta.
¿Por qué?
Necesitamos guardar todos estos datos en Salesforce.
¿Por qué?
Eso no significa ponerse difícil. Significa entender el requisito real del negocio en lugar de implementar de inmediato la solución propuesta.
Un requisito a menudo llega disfrazado de diseño.
“Necesitamos un nuevo objeto personalizado” no es necesariamente un requisito. El requisito podría ser en realidad “necesitamos llevar el seguimiento de esta información por separado”. No son lo mismo.
Una vez que entiendes el requisito real, puedes empezar a explorar alternativas. Tal vez un objeto nuevo sea exactamente la respuesta correcta. Tal vez la información pertenezca a algo que ya existe. Tal vez Salesforce no debería ser dueño de esos datos en absoluto.
El arquitecto tiene que separar lo que el negocio necesita de una forma propuesta de entregarlo.
Trabajábamos en una aplicación de ventas y el cliente tenía varias aprobaciones, cada una con un aprobador y una fecha. Lo primero que pidieron fue agregar Aprobador 2 y Aprobador 3, cada uno con su fecha, como campos en la oportunidad. Cuando profundizamos, nos dimos cuenta de que podía haber más de dos o tres. Así que pasamos las aprobaciones a un objeto hijo. La petición era tener más campos; el requisito era llevar el seguimiento de cada aprobación, fueran cuantas fueran.
Pensar más allá del requisito
Sección titulada «Pensar más allá del requisito »De preguntar por qué se desprenden dos hábitos, y cada uno tiene su propio módulo más adelante en este capítulo.
Normalmente hay más de una respuesta. Salesforce nos da muchas formas de resolver un problema, y algunas son incorrectas casi de inmediato. Elegir entre las que funcionan es el arte de las compensaciones (módulo 4).
Y los requisitos que te dan no son todos los requisitos que tienes. Nadie dice “asegúrate de que esto funcione cuando la carga nocturna solo tenga éxito a medias”, pero sigue siendo un requisito. Miro cada diseño a través de tres lentes: construye para hoy, planifica para mañana, planifica para el fallo (módulo 5).
Piensa en alguien que contrata a un arquitecto para diseñar un edificio. No pide una alarma contra incendios ni un sistema de rociadores, ni que el edificio resista un terremoto. Lo espera como parte del trabajo, sin pedirlo. Nuestro mundo funciona igual. Nadie pide un manejo de errores elegante, registros (logs) o una forma de recuperarse cuando algo falla. Le corresponde al arquitecto saber cuáles de esos sistemas pertenecen al diseño, e incluirlos.
Haz visible tu razonamiento
Sección titulada «Haz visible tu razonamiento »Un arquitecto no debería entrar a una sala y anunciar: “Esto es lo que vamos a hacer”.
Tu trabajo también es explicar por qué. Quiero que las partes interesadas entiendan las alternativas que consideramos y las compensaciones que implican. Eso no significa darle a un ejecutivo un documento de diseño de 40 páginas. Significa poder explicar la misma arquitectura a un desarrollador, al negocio y a un ejecutivo: conversaciones distintas sobre la misma decisión.
Y la forma de hacerlo es con planos e instrucciones claros, como la persona que sostiene el plano en la obra. Para un arquitecto de datos, uno de los planos más importantes es el modelo de datos.
Si nadie entiende por qué se tomó una decisión, es muy probable que alguien termine deshaciéndola. Y puede que tenga razones perfectamente razonables para hacerlo, porque nadie le explicó nunca la decisión original.
El arquitecto no necesita construirlo todo
Sección titulada «El arquitecto no necesita construirlo todo »Hay otra transición que puede ser difícil, sobre todo para quienes llegan a la arquitectura desde el desarrollo.
No tienes que construirlo todo tú mismo.
Todavía me gusta entender cómo funcionan las cosas a un nivel muy técnico, y esa base importa. Pero como arquitecto, tu responsabilidad se vuelve más grande que tu propia implementación. No tienes que construirlo todo; necesitas saber darles a quienes sí lo construyen la dirección correcta y los parámetros correctos. Eso significa entender lo suficiente para guiar su trabajo, para reconocer cuándo una implementación propuesta crea un problema de arquitectura y para moverte entre los detalles y el panorama general.
A veces eso significa profundizar en una consulta, una API o un modelo de datos.
A veces significa dar un paso atrás y preguntar si deberíamos estar haciendo algo de esto en primer lugar.
Y cada vez más, lo que construye no son solo personas. Con la IA, el arquitecto puede estar trabajando directamente con la herramienta que genera los objetos, el código y las pantallas. Entonces la dirección, los parámetros y las pautas van a la IA, y darlos bien se vuelve cada vez más responsabilidad del arquitecto. Volveremos a eso en el módulo 7.
Eso es parte del camino de constructor a arquitecto.
Tu trabajo es tomar decisiones
Sección titulada «Tu trabajo es tomar decisiones »Al final, la arquitectura trata de decisiones.
Algunas decisiones son fáciles de cambiar. Otras no.
Un formato de página se puede cambiar. Una etiqueta se puede renombrar.
Pero elige mal el modelo de datos fundamental, publica identificadores de los que decenas de sistemas empiezan a depender, o pon la copia maestra de datos críticos en el lugar equivocado, y cambiar de opinión se vuelve mucho más costoso.
Esas son decisiones de arquitectura. Y son exactamente el tipo de decisiones en las que se concentra este curso.
Como arquitecto de datos, vas a tomar decisiones sobre cómo se estructura la información, dónde vive, cómo crece, cómo se mueve, quién puede acceder a ella y cómo la entiende el resto de la empresa.
La tecnología importa.
Pero conocer cada función de Salesforce no es el objetivo.
El objetivo es desarrollar el criterio para saber qué herramienta usar, cuándo usarla, a qué estás renunciando y qué pasa después.
Eso es pensar como un arquitecto.
Y ahora podemos empezar a pensar como un arquitecto de datos.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Si una petición es un requisito real o un diseño propuesto para cumplirlo.
- Qué preguntas hacer antes de construir nada: si deberíamos, por qué de esta manera, qué otra cosa podríamos hacer, qué pasa cuando crezca o falle.
- Qué decisiones le corresponden al arquitecto y cuáles a quienes construyen; y qué dirección y parámetros darles a quienes construyen, sean personas o IA.
- Cómo explicar una decisión para que la entiendan un desarrollador, el negocio y un ejecutivo.