Архитектура — искусство компромиссов

🌐 Также доступно на 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)

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

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

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

Вопрос, на который отвечает этот модуль: Когда могут сработать несколько решений, как архитектор выбирает и объясняет свой выбор?

Если бы архитектура сводилась к поиску правильного ответа, все было бы намного проще. Выучите платформу, выучите шаблоны, выучите лимиты, выберите нужное — готово.

Настоящая архитектура так не работает. Трудные решения обычно принимаются не между очевидно хорошим и очевидно плохим вариантом. Они принимаются между несколькими решениями, которые могут сработать, у каждого свои плюсы и минусы, и каждое ведет архитектуру в немного другом направлении. Именно здесь архитектор зарабатывает свое место за столом.

Много способов решить задачу

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

В Salesforce может быть много способов решить задачу. Иногда я называю число, скажем десять, но это аналогия, а не подсчет. У многих вариантов проблемы есть с самого начала: они упираются в ограничение платформы, упускают критическое требование или создают проблему безопасности или производительности, которую мы не можем принять. Их можно быстро отложить. Некоторые другие работают сегодня, но столкнутся с проблемами, когда вырастут данные. Технически они рабочие, но не выдержат роста, который, как мы уже знаем, наступит.

Остается небольшое число вариантов, которые смогут поддерживать ваши потребности и дальше, — и вот тут становится интересно. Каждый из них может сработать, масштабироваться и удовлетворить требования. Так какой же правильный? Может быть, все. Работа архитектора — понимать разницу между ними.

Даже такая простая вещь, как список выбора, работает сегодня и может столкнуться с проблемами, когда данные вырастут. Список выбора удобен пользователям. Но спросите, откуда берутся значения и сколько их может быть. Списки выбора лучше всего работают, когда значений меньше примерно 20. Иногда мы доходим до 50, как со штатами США, и редко больше 100, как со странами, и такие уже становятся громоздкими. Так что для каждого списка выбора знайте верхнюю границу. И изменение значений списка выбора — это изменение метаданных, а не данных.

Используйте вместо него lookup, и пользовательский интерфейс станет немного сложнее. Зато список сможет расти без верхней границы, а новые значения смогут приходить из интеграции. Это компромисс с удобством использования. В этом и состоит баланс.

Click to enlarge

Оптимальный не значит идеальный

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

Допустим, решение A дает лучшую производительность, но дорогое и сложное в сопровождении. Решение B стоит меньше и проще в эксплуатации, но жертвует частью производительности. Решение C гибче на будущее, но добавляет сложности сегодня. Какое из них оптимально? Только по этим фактам я ответить не могу. Мне нужно знать бизнес, требования и приоритеты, а также какие ограничения настоящие, а какие — предпочтения. Архитектура зависит от контекста. Вот почему шаблон, который был правильным для одного клиента, может оказаться совершенно неправильным для следующего.

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

Неоптимальное решение может быть частью оптимальной архитектуры

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

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

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

Знайте, чем вы жертвуете

Когда кто-то говорит мне «это лучшее решение», мой следующий вопрос: «лучшее в чем?» Самое быстрое? Самое дешевое? Самое простое? Самое масштабируемое, самое безопасное, самое гибкое? Самое простое в эксплуатации, самое быстрое в поставке, меньше всего зависящее от редких навыков? Почти всегда есть другое измерение, где ответ не «лучшее». Это и есть компромисс. Я хочу знать, что мы получаем, и я также хочу знать, от чего мы отказываемся.

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

Требования не равноценны

Компромиссы заставляют нас увидеть и то, что не все требования весят одинаково.

Кто-то говорит: «Данные должны быть доступны мгновенно». Хорошо, а что значит «мгновенно»? Одна секунда, десять секунд, минута? И почему? Может быть, это выявление мошенничества, где важны секунды. А может быть, кому-то просто не нравится ждать ночной загрузки. Это совсем разные требования, и архитектор продолжает спрашивать, пока мы не поймем, какое у нас.

Мне нравятся требования, которые выдерживают вопросы: сколько, в каком количестве, как быстро, как часто, для кого и что будет, если мы этого не сделаем? «Быстро» — это не архитектурное требование. «95 % обновлений данных клиента должны быть доступны агенту поддержки в течение 30 секунд» — уже гораздо ближе к нему. Теперь можно оценивать компромиссы.

Ограничения меняют ответ

Иногда архитектура вообще не ограничена технологиями. Ее ограничивают деньги, люди, время, лицензии или зрелость организации.

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

Все это не значит, что мы отказываемся от хорошей архитектуры из-за дедлайна. Это значит, что мы понимаем, чем поступаемся, почему и какие последствия принимаем, а в идеале — как мы перейдем от сегодняшнего компромисса к завтрашней архитектуре.

Архитектору нужна картина «оптимального»

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

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

Нарисуйте это

Один из лучших способов понять компромисс — нарисовать его. Архитектурные диаграммы — не украшение для презентации; это инструменты мышления. Если мы выбираем между двумя подходами, нарисуйте оба. Где живут данные и куда они перемещаются? Кто ими владеет? Где границы и где обеспечивается безопасность? Что будет, когда что-то сломается, и что изменится с ростом объема?

Диаграмма вытаскивает неясности на свет и дает всем одну и ту же картинку, на которую можно указать.

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

Поскольку от встречи к встрече это были одни и те же люди, диаграмма стала нашим общим языком. Люди начали пользоваться ее названиями. Повторяющиеся вопросы ушли, и встречи стали намного легче. Я называю это заземлением встречи: простая диаграмма, которую показывают каждый раз, стоила гораздо больше, чем усилия на ее создание.

Цель — не художественное совершенство. Иногда это детальная диаграмма для инженеров, иногда пять прямоугольников и шесть стрелок для руководителя. Цель — ясность.

Объясните компромисс

Хороший архитектор излагает все по порядку: вот варианты, которые мы рассмотрели, вот что дает каждый, вот чего стоит каждый, вот вариант, который я рекомендую, и вот почему.

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

Think Correct. Think Fast.

У вас не всегда будет три недели на анализ каждого варианта. Иногда будет три минуты. На встрече меняется требование, кто-то называет ограничение, о котором вы не знали, или руководитель спрашивает: «А если в следующем году нам это понадобится в Европе?»

Я использую фразу Think Correct. Think Fast. («Думай правильно. Думай быстро.») Скорость берется не из того, что вы пропускаете обдумывание. Она берется из того, что вы достаточно обдумали еще до того, как настал момент: вы выучили шаблоны, знаете платформу, видели сбои, знаете, какие вопросы задавать и какие решения трудно отменить. Вот почему на протяжении всего курса мы разбираем сценарии. Чем больше решений вы проанализируете, тем быстрее узнаете очертания следующего.

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

Архитектура — это баланс

По мере того как мы будем углубляться в архитектуру данных, вы встретите выборы, где я не тороплюсь давать простое правило. Нормализовать или сделать плоским? Скопировать данные или федерировать? Синхронно или асинхронно? Стандартный объект или пользовательский? Архивировать или держать онлайн?

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

Знайте, как выглядит оптимальное. Понимайте ограничения. Определите жизнеспособные варианты. Сделайте компромиссы видимыми. Затем примите решение.

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

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

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