Думать как архитектор

🌐 Также доступно на 28 языках

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 · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 1 из 7 главы Думать как архитектор данных, глава 1 курса Data Architect. Каждый модуль самостоятелен. Назад: обзор главы · Далее: Модель данных — это скелет

Вопрос, на который отвечает этот модуль: В чем разница между тем, чтобы строить, и тем, чтобы проектировать архитектуру, и чем на самом деле занимается архитектор?

Большую часть своей карьеры я был строителем.

Я начинал разработчиком. Я работал с Java и .NET, прежде чем перейти в Salesforce, и годами проектировал системы, писал код, интегрировал платформы, обучал архитекторов и проводил ревью архитектур.

Но один из самых важных уроков, которые я усвоил на этом пути, такой: быть отличным строителем и быть отличным архитектором — не всегда одно и то же.

Строитель спрашивает:

Как мне это построить?

Архитектор должен задавать другие вопросы:

Стоит ли нам это строить?

Почему мы строим это именно так?

Какие есть альтернативы?

Что будет, когда это станет больше?

Что будет, когда это сломается?

И какое решение мы принимаем сегодня, о котором через три года пожалеем, что не подумали над ним получше?

Помню проект для розничного бизнеса, который работал с записями на прием. Я спросил: сколько записей в день на один магазин? Потом: сколько у вас магазинов? И сколько дней в неделю вы открыты? Очень быстро я понял, что только за первый год у нас будут миллионы записей. Вот такие вопросы архитектор задает в начале проекта.

Именно об этой смене мышления на самом деле и этот курс.

Click to enlarge

Человек с чертежом в руках

Я много раз использовал эту аналогию, когда обучал архитекторов.

Представьте себе стройку. Одни люди заливают бетон, другие тянут электрику, ставят сантехнику, возводят каркас стен и выполняют десятки других специализированных работ. Каждый из них должен очень хорошо делать свое дело.

Но кто-то должен еще и держать в руках чертеж.

Этому человеку нужно понимать, как все эти части складываются вместе. Он должен замечать, когда то, что происходит в одной части проекта, создает проблему где-то еще.

Это и есть архитектура.

В технологиях мы иногда ошибочно думаем, что архитектор — это просто человек, который знает больше всех. Дело не совсем в этом. Знать платформу важно. Нужна техническая глубина. Но архитектура — это не викторина.

Работа архитектора — принимать хорошие решения, иногда при неполной информации и конкурирующих требованиях, и понимать последствия этих решений.

Это совсем другой навык.

Не принимайте требование на веру

Одна из первых привычек, которую я хочу выработать у архитекторов, очень простая:

Спрашивайте «почему».

Вам говорят:

Нам нужен еще один объект.

Почему?

Нам нужно скопировать это поле в организацию (Account).

Почему?

Нам нужно хранить все эти данные в Salesforce.

Почему?

Это не значит быть трудным человеком. Это значит понять настоящее бизнес-требование, вместо того чтобы сразу реализовать предложенное решение.

Требование часто приходит замаскированным под проект решения.

«Нам нужен новый пользовательский объект» — это не обязательно требование. Настоящее требование может звучать так: «нам нужно отслеживать эту информацию отдельно». Это не одно и то же.

Когда вы поняли настоящее требование, можно начинать искать альтернативы. Может быть, новый объект — именно то, что нужно. Может быть, информации место там, где уже что-то есть. А может быть, Salesforce вообще не должен владеть этими данными.

Архитектор должен отделить то, что нужно бизнесу, от одного из предложенных способов это реализовать.

Мы работали над приложением для продаж, и у клиента было несколько согласований, у каждого — согласующий и дата. Сначала они попросили добавить в возможность (Opportunity) поля «Согласующий 2» и «Согласующий 3», каждое с датой. Когда мы копнули глубже, то поняли, что согласований может быть больше двух или трех. Поэтому мы вынесли согласования в дочерний объект. Просили больше полей; а требование было отслеживать каждое согласование, сколько бы их ни оказалось.

Думать дальше требования

Из вопроса «почему» вытекают две привычки, и каждой из них посвящен отдельный модуль дальше в этой главе.

Обычно ответ не один. Salesforce дает нам массу способов решить задачу, и некоторые из них оказываются неправильными почти сразу. Выбирать между теми, что работают, — это искусство компромиссов (модуль 4).

И требования, которые вам дали, — это не все ваши требования. Никто не говорит «убедитесь, что это работает, когда ночная загрузка проходит только наполовину», но это все равно требование. Я смотрю на любой проект с трех сторон: стройте для сегодняшнего дня, планируйте на завтра, планируйте на случай сбоя (модуль 5).

Подумайте о человеке, который нанимает архитектора, чтобы спроектировать здание. Он не просит пожарную сигнализацию или спринклерную систему и не просит, чтобы здание выстояло при землетрясении. Он ожидает этого как само собой разумеющегося, без всяких просьб. В нашем мире все так же. Никто не просит аккуратной обработки ошибок, логов или способа восстановиться после сбоя. Архитектор сам должен знать, какие из этих систем нужны в проекте, и заложить их.

Click to enlarge

Сделайте свои рассуждения видимыми

Архитектор не должен просто войти в комнату и объявить: «Делаем вот так».

Ваша работа — еще и объяснить почему. Я хочу, чтобы заинтересованные стороны понимали, какие альтернативы мы рассматривали и на какие компромиссы шли. Это не значит вручать руководителю 40-страничный проектный документ. Это значит уметь объяснить одну и ту же архитектуру разработчику, бизнесу и руководителю: разные разговоры об одном и том же решении.

А делается это с помощью понятных чертежей и инструкций, как у человека с чертежом на стройке. Для архитектора данных один из самых важных таких чертежей — модель данных.

Если никто не понимает, почему было принято решение, велика вероятность, что рано или поздно кто-то его отменит. И у него могут быть вполне разумные причины, ведь исходное решение никто так и не объяснил.

Архитектору не нужно строить все самому

Есть еще один переход, который может даваться непросто, особенно тем, кто пришел в архитектуру из разработки.

Вам не нужно лично строить все.

Я по-прежнему люблю разбираться, как все устроено на очень техническом уровне, и эта основа важна. Но как архитектор вы отвечаете за большее, чем ваша собственная реализация. Вам не нужно строить все; вам нужно уметь дать тем, кто строит, правильное направление и правильные параметры. Это значит понимать достаточно, чтобы направлять их работу, замечать, когда предложенная реализация создает архитектурную проблему, и переключаться между деталями и общей картиной.

Иногда это значит глубоко погрузиться в запрос, API или модель данных.

Иногда — сделать шаг назад и спросить, стоит ли нам вообще все это делать.

И все чаще строят уже не только люди. С ИИ архитектор может работать напрямую с инструментом, который генерирует объекты, код и экраны. Тогда направление, параметры и правила получает ИИ, и умение хорошо их задать все больше становится ответственностью архитектора. Мы вернемся к этому в модуле 7.

Это часть пути от строителя к архитектору.

Ваша работа — принимать решения

В конечном счете архитектура — это решения.

Одни решения легко изменить. Другие — нет.

Макет страницы можно поменять. Метку можно переименовать.

Но выберите неправильную базовую модель данных, опубликуйте идентификаторы, от которых начнут зависеть десятки систем, или поместите мастер-копию критически важных данных не туда — и передумать станет гораздо дороже.

Это архитектурные решения. И именно на таких решениях сосредоточен этот курс.

Как архитектор данных вы будете принимать решения о том, как структурирована информация, где она живет, как растет, как перемещается, кто имеет к ней доступ и как ее понимает остальная часть предприятия.

Технологии важны.

Но цель не в том, чтобы знать каждую функцию Salesforce.

Цель — развить умение судить и понимать, какой инструмент использовать, когда его использовать, чем вы при этом жертвуете и что будет дальше.

Вот что значит думать как архитектор.

А теперь можно начать думать как архитектор данных.

Что здесь решает архитектор

• Является ли запрос настоящим требованием или лишь одним из предложенных решений для него.
• Какие вопросы задать до того, как что-то будет построено: стоит ли, почему так, что еще можно сделать, что будет, когда это вырастет или сломается.
• Какие решения принимает архитектор, а какие — те, кто строит; и какое направление и параметры дать строителям, будь то люди или ИИ.
• Как объяснить решение, чтобы его поняли и разработчик, и бизнес, и руководитель.