Модель данных решения Salesforce
Какие объекты, поля и связи представляют бизнес, решённые один раз и построенные для изменений, а не переделываемые с каждым новым требованием.
Salesforce
Единый владелец дизайна того, как облака, модель данных и интеграции Salesforce складываются вместе, до того как команда разработчиков и администраторов начнёт строить.
Бизнес в Дубае обычно начинает искать Salesforce решение-архитектора, как только больше одной команды, облака или системы нужно работать с одними и теми же данными Salesforce, не противореча друг другу. Отдел продаж на Sales Cloud, служба поддержки на Service Cloud и финансовая система, которой нужны данные заказов, каждый по отдельности несложен, но в момент, когда им приходится делить записи и оставаться согласованными, кто-то должен владеть этим дизайном до того, как разработчики начнут строить по нему. Именно это владение, а не какая-то отдельная функция, и есть то, ради чего вы нанимаете Salesforce решение-архитектора в Дубае.
Роль стоит между бизнесом и сборкой. Salesforce решение-архитектор переводит реальную потребность бизнеса в целевой дизайн: какие объекты хранят какие данные, как правила совместного доступа и видимости удерживают нужных людей видящими нужные записи, где место автоматизации, а где действительно нужен кастомный код, и как организация будет подключаться ко всему, что находится вне Salesforce. Ошибитесь в этом дизайне рано, и каждая команда, строящая поверх него, унаследует проблему позже, именно поэтому роль существует как отдельный найм, а не дополнительная задача для разработчика.
Что владеет ролью
Это решения, которые Salesforce решение-архитектор принимает в Дубае до начала разработки.
Какие объекты, поля и связи представляют бизнес, решённые один раз и построенные для изменений, а не переделываемые с каждым новым требованием.
Иерархии ролей, правила совместного доступа и наборы разрешений, дающие каждой команде доступ именно к тем записям, что ей нужны, не больше и не меньше.
Как Salesforce обменивается данными с ERP, сайтом или другой системой, и какие паттерны и API подходят каждому соединению, вместо того чтобы относиться ко всем связям одинаково.
Обоснованная граница между тем, что должны обрабатывать Flow и декларативные инструменты, и где Apex по-настоящему оправдывает свою сложность.
Как Sales Cloud, Service Cloud или другое облако делят одни и те же базовые данные, не дублируя и не противореча друг другу.
Документированные проектные решения, которым разработчик или администратор может следовать, не переопределяя архитектуру в каждом тикете.
Важные навыки
Доказательства реальных проектных решений, а не просто знакомство с платформой.
| Навык или инструмент | Как выглядит хороший уровень | Почему это важно |
|---|---|---|
| Моделирование данных в масштабе | Спроектировал объектную модель, пережившую реальный рост, а не только демо-организацию | Плохая модель данных, самое сложное и дорогое, что приходится переделывать, когда бизнес уже от неё зависит |
| Дизайн совместного доступа и безопасности | Может объяснить построенную им иерархию ролей или набор разрешений и почему именно так | Слишком широкий или слишком узкий доступ одинаково вызывают реальные бизнес-проблемы позже |
| Паттерны интеграции | Знает, когда использовать вызов API в реальном времени, событие или плановый пакет, и почему | Неверный паттерн для объёма или времени данных вызывает сбои под реальной нагрузкой |
| Опыт с несколькими облаками | Реально соединял два или больше облака Salesforce вокруг одной общей модели данных | Опыт только с одним облаком не раскрывает конфликты, появляющиеся, когда облака делят данные |
| Объяснение компромиссов | Может объяснить проектное решение и его цену простым языком нетехническому заказчику | Архитектурные решения несут стоимость и риск, которые принимает не только команда Salesforce, но и бизнес |
Собственное руководство по экзамену Platform Integration Architect Salesforce описывает то самое суждение по интеграциям, которым должен обладать сильный архитектор, от оценки текущего ландшафта систем до проектирования и поддержки решения, и это честная основа для вопросов, когда вы нанимаете Salesforce решение-архитектора в Дубае.
Форматы работы с нами
Короткий консалтинговый проект обычно правильная точка входа: мы оцениваем то, что есть сегодня, или то, что запланировано, относительно ваших реальных бизнес-процессов, а затем оставляем вам письменный целевой дизайн, охватывающий модель данных, совместный доступ и подход к интеграциям, с фиксированной ценой, а не открытым временем. Растущая организация в Дубае, ведущая Salesforce по нескольким командам, часто вместо этого держит архитектора на выделенной основе, поскольку проектные вопросы продолжают возникать по мере изменения бизнеса, а не закрываются после одного проекта. Если вы хотите, чтобы этот человек постоянно был в вашем собственном штате, поддержка в подборе, правильный путь: мы пишем роль, составляем шортлист и проводим техническую оценку, а найм остаётся за вами. Разовый проект подходит для одной, ограниченной части проектной работы, например планирования того, как новое облако присоединится к существующей организации, переданной как документация, по которой ваша команда затем строит.
Оценка кандидата
Вопросы, раскрывающие, как человек реально продумывает дизайн.
Эти проверки входят в нашу собственную техническую оценку в рамках поддержки в подборе, и они работают точно так же, если вы сами собеседуете кандидатов перед тем, как нанять Salesforce решение-архитектора в Дубае.
Вместо описания диаграммы попросите кандидата объяснить одно решение по объекту или совместному доступу из прошлого проекта и отвергнутую альтернативу, и почему.
Две команды, которым нужна видимость пересекающихся записей, но разные права редактирования, честное тридцатиминутное упражнение, и то, как он рассуждает, важнее итоговой диаграммы.
У каждого опытного архитектора есть дизайн, который он теперь построил бы иначе. Тот, кто не может назвать такой, вероятно, ещё не принял достаточно реальных решений.
Спросите, что подтолкнуло прошлый проект к соединению в реальном времени вместо планового пакета, и что изменило бы этот ответ.
Попросите образец проектной документации, написанной для того, чтобы кто-то другой мог по ней строить. Сильный кандидат относится к этому как к рутине, а не как к запоздалой мысли.
Сертификации
Salesforce решение-архитектор в Дубае обычно оценивается по сертификатам, построенным из нескольких экзаменов, а не одного теста.
Salesforce присваивает эти два сертификата, как только кандидат сдаёт доменные экзамены под каждым из них, охватывающие такие области, как архитектура данных, совместный доступ и видимость для Application Architect, и интеграция и внедрение для System Architect. Тот, кто получил оба, обычно считается работающим на уровне решение-архитектора, ступенью ниже отдельно оцениваемого ревью-совета Certified Technical Architect.
Попросите профиль Trailblazer, где точно перечислено, какие экзамены сданы и когда, вместо того чтобы принимать на веру только название должности. Именной доменный сертификат, например Platform Data Architect, периодически обновляется, поэтому дату профиля тоже стоит проверить.
Особенности ОАЭ
Salesforce решение-архитектор, работающий в Дубае, должен закрыть оба этих пункта, пока план ещё на бумаге.
Архитектура Hyperforce Salesforce предоставляет локальное хранение данных в ОАЭ, а значит, решение-архитектор может спланировать, где хранятся записи, как часть исходного дизайна, вместо того чтобы переносить их, когда организация уже работает.
Как только дизайн затрагивает больше одного облака, хранящего записи клиентов или сотрудников, Федеральный декрет-закон № 45 от 2021 года задаёт базовый уровень ОАЭ для защиты этих данных и согласия на их обработку, и единую модель совместного доступа, применяемую последовательно, легче защитить, чем отдельную трактовку для каждого облака.
Эта роль относится к нашей категории Salesforce, части более широкого раздела наём разработчиков в Дубае. Как только целевой дизайн согласован, повседневное владение платформой становится задачей нашей страницы Salesforce администратор, а техническая сборка любых связей, названных в дизайне, относится к нашей странице Salesforce интеграционный разработчик. Программы, охватывающие целое предприятие, а не только Salesforce, ближе к нашей роли Salesforce технический архитектор, а наша более широкая страница облачные услуги покрывает архитектурные вопросы за пределами Salesforce.
Прямые ответы
Консультант работает в основном внутри одного облака, настраивая его под бизнес-процесс. Salesforce решение-архитектор проектирует по облакам и системам, решая, как Sales Cloud, Service Cloud или кастомное приложение, модель данных и любые интеграции складываются в один согласованный дизайн до начала сборки.
Обычно нет как отдельный проект. Внедрение в одном облаке для одной команды обычно хорошо покрывается консультантом и администратором, работающими вместе, а архитектура решается как лёгкий консалтинговый обзор, а не отдельная фаза дизайна.
Некоторые пишут, но роль в первую очередь про дизайн, обзор и решения, а не про продакшн-код. Многие решение-архитекторы могут прототипировать компонент, чтобы доказать выбор дизайна, а затем передать детальную сборку разработчику.
Salesforce технический архитектор, иногда называемый Certified Technical Architect, стоит выше решение-архитектуры и оценивается собственным ревью-советом Salesforce по всей корпоративной программе. Решение-архитектор обычно владеет дизайном одной программы или определённого набора облаков внутри неё.
Да, через консалтинг. Мы оцениваем текущую модель данных, правила совместного доступа и интеграции относительно ваших реальных бизнес-процессов и передаём письменный набор выводов и целевой дизайн, а не общий чеклист.
Источники
Фиксированная цена в письменном виде
Получили. Мы уже готовим ваше предложение.
В рабочее время вы получите его в течение 45 минут. Проверьте почту, там письмо с подтверждением.