При создании сложного ПО (а e-commerce системы зачастую бывают достаточно сложны, особенно если речь идет о крупных игроках рынка) разработчики и архитекторы не изобретают все сами, а опираются на определенный «фундамент», который делает разработку управляемой, а всю систему обозримой и понятной. Этот фундамент представляет собой «многослойный рулет», состоящий из универсальных, типовых и хорошо зарекомендовавших себя технологий и продуктов. Выбор такого набора во многом определяет развитие системы на многие годы. Бывает так, что упомянутый «рулет» содержит всего два слоя «муки и корицы», а иногда – там есть еще пять вариантов разного «джема» и пр. Примеры составляющих такого «рулета» — Hadoop, Apache Tomcat, NodeJS, PHP-FPM, JBoss, ORM, Search Engine и другие. Конкретный набор используемых технологий определяется масштабом и целями проекта, опытом команды разработчиков, потребностями бизнеса.
Если внимательно взглянуть на популярные e-сommerce платформы, то окажется, что в них есть много общего. И хотя мы имеем тут свой, достаточно обширный, зоопарк технологий — Java, C++, PHP, Apache Solr и др. , но в общем случае разные платформы строятся с использованием похожих составляющих, которые собираются для реализации вполне определенного набора обязательных и дополнительных функций. Таким образом, e-commerce платформа представляет собой органичный, подготовленный, настроенный, отлаженный, упакованный и документированный набор технологий. Под многие типичные задачи e-commerce вендоры платформ предоставляют готовые блоки, которые требуют лишь небольшой «подгонки» под задачу, а некоторые реализованы на абстрактном уровне и требуют «допиливания напильником». Чем органичнее переплетены между собой технологии, чем продуманнее архитектура, тем легче будет расширять ее под свои задачи.
Минимальная системная инфраструктура, необходимая для успешного развертывания и эксплуатации типового интернет-магазина (торговой площадки), включает в себя: web-сервер, сервер приложений, подсистему работы с данными (database engine). Для защиты системы от несанкционированного доступа и сетевых атак также необходим соответствующий сетевой шлюз (firewall). Причем, несмотря на наличие нескольких звеньев, все они могут работать в рамках одной или нескольких виртуальных или физических машин.
Как правило, даже в случае небольших торговых площадок одним из важнейших требований является минимизация простоя и возможность быстрого восстановления в случае сбоев в системе. Кроме того, для подавляющего большинства торговых систем и интернет-магазинов критически важной является скорость, с которой они способны обслуживать покупателей даже в периоды высоких нагрузок. Так что для всех звеньев такой системы становятся востребованы специальные средства кэширования, кластерные решения, поисковая машина и средства мониторинга, которые позволяют оперативно отслеживать состояние и работоспособность системы и различных ее узлов. Средства обеспечения безопасности, необходимые для отражения сетевых атак и угроз, также востребованы в любой полноценной e-commerce системе, так как нормальное функционирование публичных торговых площадок без соответствующих механизмов практически не возможно.
Рассматривая разные e-commerce платформы можно разбить их на две группы решений. Первая группа ориентирована на относительно легковесные решения, для которых максимальная централизация всех звеньев (в идеале – размещение их на единственной виртуальной или физической машине) является благом и ведет к упрощению обслуживания и увеличению производительности системы в целом. К такой группе можно отнести практически все решения на PHP (или, более широко, – LAMP/LNMP). Сюда входят: VirtueMart, Magento и 1С-Битрикс: Управление сайтом.
Вторая группа предназначена для создания сложных и распределенных систем, для которых заведомо невозможно объединение всех функций в рамках 1-2 виртуальных или физических машин, а нагрузки в процессе эксплуатации могут колебаться в очень широких пределах. Такие системы имеют гораздо более сложную архитектуру еще и в связи с тем, что в них выделяются отдельные дублирующие фермы серверов исключительно для целей выполнения разработок, подготовки изменений в контенте, тестирования. Разделение различных звеньев по различным виртуальным или физическим машинам в подобных случаях является естественным и доставляет дополнительную гибкость и возможности в части резервирования, кластеризации, повышения производительности. К таким действительно мощным и гибким платформам можно отнести: IBM Websphere Commerce, Oracle Commerce, SAP hibris. Дополнительным «свойством» этих систем является поддержка гетерогенных конфигураций и набора различных СУБД enterprise-класса.
Совершенно отдельную категорию составляет платформа Demandware. Являясь «облачным» решением, эта платформа снимает с владельцев e-commerce площадки любую головную боль об архитектуре и производительности, т. эта задача решается самим разработчиком платформы. Вместе с тем для нее проявляются другие проблемы, связанные с ограничениями в настройках «под себя» и определенной зависимостью от текущих решений владельцев «облачного» сервиса.
Учитывая разноплановый характер деятельности компаний из сферы ретейла и услуг, мы исходим из того, что в этом бизнесе востребован широчайший спектр самого разного инфраструктурного и прикладного программного обеспечения. Настоящий раздел «Платформы» посвящен более конкретному вопросу – комплексной автоматизации каналов электронной торговли на базе многофункциональных программных платформ.
Хотя мы говорим об электронной коммерции как об отдельном направлении в деятельности сегодняшнего ретейла, следует понимать, что современная концепция омни-каналов во многом размывает границы между цифровым пространством и обычным офлайном. Поэтому многие принципы автоматизации и организации цифровой торговли и маркетинга сегодня становятся всеохватными и активно перетекают в офлайн, создавая симбиоз с традиционными «уличными» практиками. Все это накладывает дополнительный отпечаток и на программные платформы, используемые бизнесом для автоматизации торговой и маркетинговой деятельности.
Не претендуя на всеохватность, далее мы выделяем наиболее мощные, имеющие хорошие перспективы развития, программные платформы (продукты), которые получили распространение на российском рынке. Общей чертой этих продуктов следует признать то, что они появились и развивались долгое время как фреймворки (инструменты, библиотеки) для создания и поддержки сайтов интернет-магазинов, далее – более обще – как средства для автоматизации каналов электронной коммерции, а сегодня уже претендуют на еще более широкий охват, включая в себя и средства автоматизации внутренних бизнес-процессов предприятия, управления складом, маркетинговый инструментарий и т.
Настоящий обзор не имеет своей целью рейтингование программных платформ в части их рыночной доли или функциональной насыщенности. Мы исходим из того, что каждый из описываемых продуктов является востребованным в своей нише (на своем сегменте рынка, для своей категории пользователей). Вместе с тем, более глубокое понимание возможностей продукта всегда является полезным и позволяет строить более взвешенные стратегии, использовать преимущества того или иного продукта во благо своего бизнеса, не наступать на очевидные «грабли» при внедрении, правильно планировать сроки и ресурсы. И, наконец, мы пристрастны и полагаем, что у одних продуктов есть будущее и потенциал, а другие обречены на постепенное «вымирание». Поэтому и наш список платформ для более детального рассмотрения достаточно краток:
- IBM WebSphere Commerce – представляет собой мощную платформу электронной коммерции, которая позволяет строить глобальные торговые системы, обеспечивая непрерывное согласованное взаимодействие с клиентами по множеству разных каналов, включая также взаимодействие непосредственно в магазине (омни-канальная модель);
- Oracle Commerce – семейство продуктов корпорации Oracle, предназначенных для создания и управления крупными омни-канальными e-commerce площадками различной направленности;
- SAP hybris – позволяет автоматизировать торговлю в сегментах B2B и B2C и включают в ряд омни-канальных инструментов: средства для управления основными данными, управления заказами, средства ремаркетинга, а также дополнительные функции поиска и продвижения товара;
- Demandware – достаточно популярная «облачная» платформа, направленная исключительно на обслуживание крупного e-commerce;
- 1С-Битрикс: Управление сайтом (1C-Bitrix) – очень популярная России профессиональная система управления веб-проектами, универсальный программный продукт для создания, поддержки и успешного развития: корпоративных сайтов, интернет-магазинов, информационных порталов, сайтов сообществ, социальных сетей и других веб-проектов;
- Magento – высокопроизводительная и хорошо масштабируемая платформа для построения е-commerce систем разного класса;
- VirtueMart – компонент для построения e-commerce решений на базе популярных CMS с открытым кодом Joomla и Mambo.
В этом списке в верхней части расположены четыре ведущие платформы, которые используют крупнейшие мировые ретейлеры – IBM WebSphere Commerce, Oracle Commerce, SAP hybris и Demandware. Если говорить о России, то здесь пока есть только один явно выраженный лидер – 1С-Битрикс: Управление сайтом, который очень популярен (вполне заслуженно) у малого и среднего бизнеса, а крупные локальные игроки используют его вероятно потому, что унаследовали из тех времен, когда они еще не считали себя крупными. Magento и VirtueMart, очень популярные среди мелкого и среднего бизнеса в мире, в России полностью вытеснены в специфические ниши и по количеству инсталляций не могут соперничать с 1С-Битрикс: Управление сайтом.
Пришла пора подумать о роли информации в проектировании взаимодействия и ее архитектуре, особенностях и о том, как над ней работать. Большую часть времени мы проектируем интерфейсы и исследуем их восприятие пользователями. Но при этом приходится учитывать, что большинство интерфейсов — не самоцель, а всего лишь посредники во взаимодействии между человеком и информацией. Поэтому самой информации, ее архитектуре, и восприятии человеком информации справедливо уделять существенное внимание. Сегодня мы поговорим об информационной архитектуре (далее — ИА).
Для нетерпеливых или тех, у кого мало времени: итоги вкратце и интересные ссылки в конце текста.
Начнем с очевидностей. Очевидность #1: Информация нужна людям, чтобы принимать решения. Очевидность #2: Информация может быть:
- Неполной — ее не хватает для удовлетворения информационных запросов пользователя;
- Некорректной — она не соответствует действительности;
- Избыточной — ее слишком много и/или она слишком сложна для восприятия пользователем;
Очевидность #3: В любом из вышеперечисленных случаев вся работа над красотой, элегантностью и функциональностью интерфейсов представления информации теряют смысл. К примеру, при ложной информации идеальный интерфейс позволит пользователю быстро принять ложное решение. Очевидность #4: Информация организована в некую структуру, которая имеет архитектуру. Очевидность #5, итоговая: Если пользователь не находит нужную информацию или не воспринимает ее, заказчик или компания теряют прибыль. В ходе работы UX-дизайнером в сфере ecommerce, я столкнулся с многообразием представлений об информационной архитектуре. Большей частью, ее воспринимают как один из несущественных аспектов проектирования взаимодействия. Как следствие, работе над информационной архитектурой не выделяется ни ресурсов, ни времени. В конечном итоге страдают пользователи, а компании теряют значительную долю доходов.
Пожалуй, это основная причина, побудившая меня написать статью, которую я предлагаю вашему вниманию. Она разбита на несколько глав, в которых я предлагаю рассмотреть следующие вопросы:
- Что такое информационная архитектура как явление, ее место в общем процессе проектирования взаимодействия;
- Какова специфика работы над информационной архитектурой для ecommerce;
- Как мы принимаем решения. Немного психологии;
- Как спроектировать информационную архитектуру на практике.
Рассказать подробно обо всем в рамках одной статьи — цель невыполнимая, поэтому прошу оставлять пожелания и вопросы в комментариях, и я постараюсь на все ответить в последующих частях.
Что ж, приступим.
Зачем работать над информационной архитектурой?
Все совпадения с реальными персонажами, сервисами и продуктами — случайны.
Что случилось с Иваном Владимировичем
Иван Владимирович вернулся домой в полночь из-за того, что сильно задержался на работе. В принципе, он задерживался довольно часто. Это бы его не так сильно беспокоило, если бы не одно обстоятельство: ему под вечер сообщили, что их нового шефа завтра день рождения.
С самим подарком Иван определился довольно быстро: было известно, что из спиртного шеф отдает предпочтение хорошему рому. Но ситуация в целом складывалась безысходная. Многочисленные известные ему магазины элитного алкоголя были закрыты, а празднование начнется с самого утра. Судя по всему, придется воспользоваться интернет-магазином. Интернет Иван Владимирович недолюбливал и пользовался им в основном для чтения новостей. Скрепя сердце, он сел за свой ноутбук и приступил к поиску.
Его выбор остановился на магазине «Eliteboose. com», о котором он слышал, что самый лучший выбор спиртного. С первого взгляда Ивана Владимировича впечатлил стильный и аккуратный дизайн сайта.
Пробежав глазами по меню, он задумался. Ром не был одним из его любимых напитков, и разбирался он в нем, откровенно говоря, неважно. Если подумать, ром подпадает под любую из этих категорий, за исключением аперитива. После недолгого раздумья, Иван Владимирович решил перейти в «Подарки», как наиболее подходящий его нуждам пункт меню.
Он минут с 15 полистал предлагаемые продукты. К его разочарованию, рома в списке товаров не было. А предлагаемые подарки были далеки и от его нужд и от финансовых возможностей.
Уже сильно хотелось спать, но Иван Владимирович предпринял еще одну попытку, перейдя в другой пункт меню — «Для друзей». Среди многочисленного пива, водки и ликеров он наконец заметил и одинокий ром, притаившийся в конце списка. Бутыль Demo Anejo возможно была и неплохим выбором, но его смущало отсутствие выбора. Да и врял ли его шеф — руководитель департамента одного из ведущих банков страны — оценит подарок ценою всего лишь 13 долларов США.
Иван Владимирович вышел на балкон перекурить. Потом вернулся, сел за ноут и предпринял третью и последнюю попытку: выбрал пункт меню «Для застолья». И тут свершилось долгожданное чудо: он узрел впечатляющий список разнообразнейшего рома любой ценовой категории. Поразмышляв над списком пару минут, он добавил в корзину пятнадцатилетний ром Gran Demo Blender и с легкостью прошел процедуру заказа. Иван Владимирович был доволен собой но предчувствие колоссального недосыпа существенно отравляло настроение.
Утром Иван Владимирович окончательно убедился в оправданности своей нелюбви к интернет-магазинам. Выпив пару чашек кофе, он поклялся себе узнавать о предстоящих мероприятиях исключительно заранее, чтобы приобретать подарки в обычных магазинах спокойно и без стресса.
А теперь в цифрах
В вышеуказанной истории налицо проблема с ИА, пусть и утрированная. У Eliteboose. com мы видим нечетко очерченные и наименованные категории, неочевидную классификацию товаров по категориям.
Можем констатировать факт, что с Иваном Владимировичем магазину Eliteboose. com весьма повезло. Наш герой был а) достаточно упрям, чтобы не забить на идею купить ром в интернет-магазине, б) достаточно принципиален, чтобы не отказаться от покупки подарка в целом и в) достаточно инертным для того, чтобы уйти в конкурирующий интернет-магазин.
Но, полагаю, не будет сильно далеким от реальности предположение, что большая часть потенциальных покупателей оставила бы попытку найти нужный алкоголь в Eliteboose. com после первой, или уж точно после второй попытки. Таким образом, мы можем посчитать недополученный доход магазина.
Адаптируем подход Джареда Спула (Jared Spool), который он использовал для расчета стоимости фрустрации пассажиров от проблем с юзабилити для транспортной компании Amtrak:
- Вычисляем идеальный потенциальный доход — Iideal=a*b, где а и b — средний чек и кол-во потенциальных покупателей (лидов) в день
- Получаем совокупный недополученный доход — Iforgone= Iideal -( Iideal *x/100), где x — доля отказов от покупки в целом
- Узнаем стоимость ошибки в ИА — IAcost= Iforgone *y/100, $3500*20/100, где y — доля отказов по вине ИА.
- кол-во потенциальных покупателей (лидов) в день — 50;
- доля отказов от покупки — 70%;
- из них, по вине ИА — 20%.
- Идеальный доход — $100*50=$5000 в день
- Совокупный недополученный доход -$5000-($5000*70/100)=$3500 в день
- Стоимость ошибки в ИА — $3500*20/100 = $700 в день
Делаем вывод: Стоимость погрешностей в ИА — $700 в день, $21. 000 в месяц или $252. 000 дохода в год.
В случае с корпоративным ПО, потери в потраченном времени сотрудников будут ничуть не менее существенными.
Но прежде чем переходить к решению проблемы, резонно возникает следующий вопрос: «А что мы понимаем под информационной архитектурой?»
Что такое информационная архитектура?
Возьмем среднестатистического сотрудника IT-предприятия и зададим вопрос: что такое информационная архитектура, и зачем она нужна? Среди ответов, которые мы получим, с вариациями могут быть следующие:
- «Это то, как организована информация? Где и что находится?»;
- «Что-то из юзабилити, для удобства пользования сайтом?»;
Все ответы имеют отношение к действительности, но разные в плане понимания явления ИА. Но скорее всего все опрошенные согласятся, что хорошая ИА — это полезно, а плохая — вредно. Если спросить об этом своих клиентов, вариативность мнений возрастет в разы. А после изучения фундаментальных трудов по ИА станет очевидной истина, что существует несколько пониманий ИА даже в среде самих информационных архитекторов.
Ричард Сол Вурмен
Отец информационной архитектуры, Ричард Сол Вурмен (Richard Saul Wurman), дает следующие определения информационной архитектуре:
- «Нахождение и организация паттернов, присущих данным. Для того, чтобы делать сложное — простым»;
- «Создание структуры или карты информации, чтобы позволить пользователям найти свой личный путь к знаниям»;
- «Возникающая в XXIом веке профессия, фокусирующаяся на ясности, понимании человека и науке организации информации».
Питер Морвиль и Луи Розенфельд в классической работе по ИА «Информационная архитектура в интернете» приводят целых четыре определения:
- Сочетание схем организации, предметизации и навигации, реализованных в информационной системе.
- Структурное проектирование информационного пространства, способствующее выполнению задач и интуитивному доступу к содержимому.
- Искусство и наука структурирования и классификации веб-сайтов и интрасетей с целью облегчения пользователям поиска информации и управления ею.
- Развивающаяся дисциплина и сообщество практиков, ставящее своей задачей распространение принципов проектирования и архитектуры на цифровых просторах.
К Морвилю и Розенфельду присоединяется и Донна Спенсер, которая опирается на их определения в своей работе «Practical Guide to Information Architecture».
Несмотря на очень широкое понимание термина, было бы неплохо сформулировать определение и понимание ИА с точки зрения практика в проектировании взаимодействия.
Предлагаю следующее (которое не противоречило бы вышеуказанным подходам к пониманию ИА):»ИА — это схема организации информации сайта»
Лаконично и весьма абстрактно. Измеряемые показатели качества ИА должны быть вполне конкретными:
- Скорость нахождения информации (KPI: кол-во шагов для нахождения информации или затраченное время);
- Качество найденной информации (KPI: качественный показатель соответствия информации ожиданиям пользователя, от 1 до 10).
Следует отметить, что ИА присутствует всегда, в любом приложении. Вопрос только в ее соответствии пониманию и потребностям пользователя.
Отсюда вопрос номер два: Если она так важна, каким образом интегрировать работу над ИА в общий процесс проектирования взаимодействия?
Как работать над информационной архитектурой?
Мне близка точка зрения Дэна Саффера (Dan Saffer), который в своей работе «Designing for Interaction» рассматривает четыре практических подхода к проектированию взаимодействия, которые я привожу ниже. Как целесообразно работать над ИА в рамках каждого из подходов?
Ориентированный на пользователя (User-centered)
Фокус: Цели и нужды пользователя
Суть подхода: Дизайнер вовлекает пользователей в рабочий процесс, начиная с самого начала и в течение всего проекта. Постоянные консультации с пользователями, тестирование после каждого этапа проектирования. В случае конфликта мнений дизайнера и пользователя по поводу любого элемента интерфейса, мнение пользователя имеет абсолютный приоритет.
Где используется: крупные продуктовые компании, стартапы и digital-агентства.
Особенности: Подход может быть непригодным для сайтов, рассчитанных на большое количество пользователей и с широким позиционированием (т. в ходе исследования дизайнер будет опираться на мнение только узкого круга пользователей).
Место ИА: Ввиду специфики подхода — основного акцента на исследованиях — можно спокойно пустить в ход львиную долю инструментов ИА (детальнее про инструментарий напишу отдельно) без потери времени и бюджета. Самая затратная часть — набор исследуемых пользователей — оплачивается в любом случае т. они уже и так принимают участие в UX-исследованиях и тестированиях. Проектирование ИА будет идти по классической схеме сверху вниз.
Подпроцесс создания ИАЗаметка: метод исследования «Карточная сортировка» — далеко не единственный. Отличный сравнительный обзор методов исследования ИА описан Джимом Россом тут.
Ориентированный на деятельность (Activity-centered)
Идея: Отталкиваемся от задач пользователя.
Фокус: Деятельность пользователя.
Суть подхода: Деятельность состоит из действий и решений. Дизайнер исследует действия, которые пользователь делает и решения, которые ему нужно принять. Базируется на исследовании, но в меньшей степени, чем предыдущий подход. После этого формирует список задач, стоящих перед пользователем, и, основываясь на них, предлагает решение.
Где используется: Как стартапы, так и аутсорсинговые компании.
Место ИА: Также можно разрабатывать ИА во взаимодействии с пользователями без особых потерь времени и бюджета. Но нужно отталкиваться от задач пользователя, и того, какая информация должна помочь пользователю решить каждую конкретную задачу в ходе его деятельности. Только после этого будет иметь смысл переходить на более высокий уровень. Таким образом, проектирование ИА будет идти снизу вверх.
Дизайн системы (Systems design)
Идея: Пользователь — часть окружающей его системы.
Фокус: Окружение пользователя.
Суть подхода: преимущественно аналитический подход. Дизайнер должен уделять основное внимание контексту использования сайта. Определяются и видоизменяются состояния системы, окружение, цели деятельности системы относительно окружения и отклики системы на внешние возмущения.
Где используется: Digital-агентства, крупные продуктовые компании.
Особенности: Целесообразно использовать только в тех случаях, когда создается сложный продукт или система продуктов. Как правило, подход требует работы целой группы проектировщиков и дизайнеров.
Место ИА: непосредственное исследование и проектирование ИА здесь заменяется работой над архитектурой системы, с иным инструментарием и подходами.
«Гениальный» дизайн (Genius design)
Идея: Дизайнер — всему голова.
Фокус: Собственное понимание дизайна, эвристики дизайна (примеры можно посмотреть у Nielsen Norman Group).
Суть подхода: Дизайнер самостоятельно проектирует взаимодействие, базируясь на своем опыте и понимании вопроса и сверяясь с заданными эвристиками.
Где используется: аутсорсинговые компании и стартапы.
Место ИА: Ввиду ограничений по времени и ресурсов полноценные исследования по ИА провести сложно. Поэтому дизайнеры периодически самостоятельно создают схемы информационной архитектуры, в произвольной форме, исходя из своего понимания и нужд проекта.
В случае с проектированием информационной архитектуры для ecommerce проектов, есть несколько специфических моментов, которые мы детально рассмотрим в следующей главе.
Подведем промежуточные итоги.
Итоги или вкратце для тех, кому лень
Что такое Информационная архитектура (ИА) — это схема организации информации.
- Скорость нахождения информации;
- Качество найденной информации.
Кто придумалРичард Сол Вурмен.
В чем проблемаУбытки от «некачественной» ИА не сильно очевидны, скрыты в виде недополученного дохода, но достаточно существенны (могут достигать половины недополученного дохода и больше). Как следствие их неочевидности:ИА часто приносят в жертву в ходе процесса работы над проектированием взаимодействия.
Что дальшеВ следующей главе мы рассмотрим построения информационной архитектуры для электронной коммерции, и подводные камни этого процесса.
Что почитатьЕсли тема вас заинтересовала, рекомендую почитать следующие статьи:
- Краткая история ИА (англ.);
- Кейсы, предоставленные институтом информационной архитектуры (англ.);
- Являюсь ли я информационным архитектором? (PDF., англ.);
- Топ-10 ошибок в информационной архитектуре (англ.);
- Немного о методе карточной сортировки (англ.);
- Разница между ИА и навигацией (англ.).
Или, если сильно заинтересовала, предлагаю вашему вниманию следующие книги:
- Информационная архитектура в Интернете (П.Морвиль и Л.Розенфельд, рус.) — одна из базовых книг по ИА, причем из тех немногих, которые были переведены на русский;
- A Practical Guide to Information Architecture (D. Spencer, англ.) — тоже базовая, но я нашел только в англоязычном варианте;
What are the differences between them, you might ask, or why can’t we just have all the information in one layout?
We could have just one diagram to fulfill the purpose of all 3, but that diagram would be very crowded, hardly maintainable, and not clear enough for ease of understanding. To fit into UI elements, you will have to make tradeoffs and skip architecture elements to keep it clean. Having one diagram to handle one job and one logical view will allow you to ensure readability and maintainability along with other software quality attributes.
We can understand the differences between the diagrams if we examine what each diagram should ideally contain.
Enterprise architecture diagrams should ideally contain all the systems that are part of your e-commerce project highlighting the connections between systems. If you have ESB or API manager do not include either in this diagram. The purpose of this diagram is to show what system connections you will have, for example, that system A will connect to system B and system C. That link should not contain any type of relationship, or multiple connections between the same entities. Connection, in this diagram, refers to a single line between two systems that shows that there will be some data exchange. In this diagram, we also include the name of the third-parties. For example, if your payment system provider (PSP) is Cybersource, you will have an object entity with name PSP and Cybersource to showcase that you have a PSP, and that this PSP is Cybersource. The final point, but of equal significance, is to include in each system entity on the diagram what are the main functionalities, features, or roles they will play in your e-commerce project. For example, PSP CyberSource on this diagram shows that it will handle Payment and Fraud validation.
Enterprise Architecture Diagram: Sample (without legend)
Please note that the above diagram is missing the legend, as this is just an illustration. For the actual diagram a legend is a must-have.
Data flow architecture diagram: Sample
Enterprise middleware usage architecture diagram: Sample (without legend)
Enterprise, Data flow, Enterprise middleware usage architecture diagrams do not limit the amount of possible visualizations you can have on your project. You can have an end-to-end flow diagram for any customer scenario, or your system design diagram, where you show layering and how your SFCC B2C cartridges will leverage each other, override or extend. How you will manage CI/CD is also a possible visualization and much more.
The Must-have visualizations every E-Commerce Project Platform should contain.
With each significant milestone we all reflect on the things we have done, and the ways in which we could have done them better. This internal process is valid and very logical; as with each experience we grow and learn new things. These lessons teach us where we went wrong, and how we can improve our decision making process going forward. With the information gained from our experiences we can start implementing new procedures and bring ever increasing value to ourselves and our organizations.
It is natural and expected that we will go through these phases of reflection, analysis and adjustment so that we are continually improving.
I experienced this all the time when I was actively coding as a developer and I still have the same experience now that I am a Solution Architect. What I can say at this stage is that it is a natural part of the process of continued growth and evolution.
Each e-commerce project should have:
- Enterprise architecture diagram
- Data flow architecture diagram/s
- Enterprise middleware usage architecture diagram