Архитектор данных в эпоху ИИ

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

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

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

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

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

ИИ меняет архитектуру, но, возможно, не так, как люди думают поначалу.

Вспомните, с чего началась эта глава: большую часть карьеры я был строителем. Почти все это время создавать программное обеспечение было дорого. Нужны были люди со специальными навыками, а написание кода, построение интеграций, создание приложений и тестирование отнимали время; даже проверить идею было ощутимой инвестицией. ИИ меняет это уравнение. Сегодня я могу описать, чего хочу, и ИИ на удивление быстро сгенерирует модель данных, Apex, Flow, компонент Lightning, интеграцию, тесты или документацию, а завтра он сможет еще больше.

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

ИИ — это ракетный ускоритель

Я использовал эту аналогию в своих выступлениях:

ИИ — это ракетный ускоритель. Архитектура — это система наведения.

ИИ дает нам невероятное ускорение. Мы можем генерировать приложения, модели данных, интеграции, тесты и документацию быстрее, чем когда-либо. Но ракетный ускоритель не решает, куда должна лететь ракета. Он дает тягу. Курс определяет система наведения, и она же вносит поправки по пути.

Без надежного наведения больше тяги не помогает. Она просто быстрее доставит вас не туда. Работа архитектора не в том, чтобы все замедлять; она в том, чтобы мы ускорялись в правильном направлении.

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

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

Дешевая реализация смещает ценность

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

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

Генерация — это не суждение

ИИ очень хорошо генерирует варианты, и это чрезвычайно полезно. Я прошу его предложить три способа что-то смоделировать, назвать компромиссы, оспорить архитектуру, рассказать, что будет при 100 млн записей или где проект может сломаться, или дать мне альтернативу, где Salesforce не является системой записи. Я хочу, чтобы архитекторы так делали.

Но генерировать варианты и оценивать их — разные вещи. ИИ может рассказать, что предлагает вариант A и что — вариант B. Но кто-то все равно должен понимать бизнес настолько, чтобы знать, какие преимущества важны, какие ограничения настоящие, какой риск приемлем и когда ответ технически правдоподобен, но неправилен для этой организации. Это суждение, и это архитектура.

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

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

Тест на обратимость по-прежнему действует

Вернитесь к вопросу из модуля 3: насколько трудно будет отменить это решение? ИИ меняет стоимость генерации и изменения программ. Он не меняет стоимость изменения реальности. Когда 100 млн записей загружены, они существуют. Когда от идентификатора зависят двенадцать систем, эти зависимости существуют. Когда клиенты пользуются процессом или аналитика зависит от смысла поля, изменение влечет последствия. А когда данные попали туда, где им быть не следовало, никакой новый код их оттуда не вернет.

Необратимое по-прежнему необратимо.

Агенты — новый вид потребителей данных

Раньше мы проектировали данные для двух видов потребителей: людей и программ. Человек читает запись; отчет, интеграция или приложение читает данные. Теперь появился третий: агенты. Агент может извлечь данные, интерпретировать их, объединить с другой информацией, принять решение и действовать — иногда без всякого человека посередине.

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

И плохие данные не становятся умнее оттого, что их читает ИИ. Принцип «мусор на входе — мусор на выходе» по-прежнему действует. Дубликаты клиентов, неясное владение, несогласованные идентификаторы и конфликтующие системы записи не исчезают, когда вы подключаете агента; просто последствия становятся заметнее. Человек смотрит на поле и знает, что его никто не обновлял три года. У агента нет этого знания, накопленного в организации, и он может уверенно действовать на основе данных, которым все остальные молча знали, что верить нельзя. Архитектура данных становится частью архитектуры ИИ.

Следите за разрастанием схемы

ИИ еще и делает создание чего угодно невероятно легким. Нужен еще один объект, еще шесть полей, еще одна автоматизация? Сгенерируйте. Каждое решение кажется дешевым, но вспомните архитектурную гравитацию из модуля 3: эти объекты и поля обрастают зависимостями (автоматизация, интеграции, отчеты, агенты), и скоро у вас модель данных, которую никто не проектировал. Она просто выросла.

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

Проверка человеком — не формальность

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

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

ИИ не сокращает путь

Есть фраза, которую я использую, когда говорю о том, как стать архитектором:

ИИ не сокращает путь. Он может сделать так, чтобы каждый шаг значил больше.

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

Архитектор направляет

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

Вот почему последний уровень этого курса называется Direct (направлять). Возможно, вы не будете писать каждую строку кода, создавать каждый Flow или строить каждый объект. Но кто-то все равно должен направлять решение, и это архитектор. ИИ не уничтожает архитектуру; он меняет то, где архитекторы создают ценность. Сейчас удивительное время, чтобы стать архитектором.

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

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

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