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

Здесь легко запутаться. В один ряд часто ставят WordPress, «1С-Битрикс», headless CMS и собственную разработку. Но это не совсем корректное сравнение.

Готовая или собственная CMS — это вопрос о том, берем мы уже существующий продукт или создаем систему под конкретный проект. Классическая или headless — вопрос о том, как CMS связана с самим сайтом.

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

Поэтому правильнее не пытаться найти один список «видов CMS», а разобраться в этих различиях отдельно.

 

Почему готовая, собственная и headless — не три одинаковых типа CMS

Представим два корпоративных сайта.

Первый работает на готовой CMS. Второй — на системе, которую разработали специально для компании.

Это различие по происхождению системы.

Теперь другой пример. У одной компании CMS сама формирует страницы сайта. У другой она только хранит контент, а сайт получает данные через API и отображает их отдельно.

Это уже различие по архитектуре.

Получается, что готовая CMS вполне может быть headless. Собственная тоже.

Именно поэтому дальше разделим эти вопросы.

 

Готовая CMS

Готовая CMS — это программный продукт, который существовал еще до начала конкретного проекта.

Например:

• WordPress;
• Drupal;
• «1С-Битрикс: Управление сайтом».
  
  

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

Разработчики не создают все это заново. Они настраивают CMS под проект, реализуют дизайн, типы контента, дополнительные функции и интеграции.

Для обычного корпоративного сайта это часто разумная отправная точка.

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

Где начинаются ограничения готовой CMS

Сам факт доработки еще не означает, что система выбрана неправильно.

Практически любой корпоративный проект требует каких-то дополнительных модулей, интеграций или изменений стандартной логики.

Проблема появляется позже — когда исключений становится слишком много.

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

Каждую такую задачу можно решить.

Но в какой-то момент возникает вопрос: мы все еще используем возможности готовой CMS или уже в основном обходим ее ограничения?

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

 

Собственная CMS

У собственной CMS другая отправная точка.

Сначала команда разбирается с тем, какие данные есть в системе, кто с ними работает, какие нужны права, статусы и интеграции. После этого под эти требования проектируется система управления.

Это не означает разработку абсолютно всего с нуля.

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

Допустим, компания управляет большой сетью объектов.

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

Готовую CMS тоже можно под это настроить.

Но в собственной системе объект сразу становится одной из базовых сущностей, а права, связи и процессы проектируются вокруг него.

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

У собственной CMS есть цена

Собственная разработка дает больше контроля, но этот контроль приходится оплачивать.

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

После запуска ответственность тоже остается у команды проекта.

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

Поэтому писать свою CMS только ради «гибкости» — слабая причина.

Своя система оправдана тогда, когда эта свобода действительно нужна проекту и используется постоянно.

 

Готовая или собственная CMS: в чем разница

Критерий	Готовая CMS	Собственная CMS
Базовые функции	Уже есть	Нужно разработать или интегрировать
Скорость старта	Обычно выше	Обычно ниже
Затраты на старте	Обычно ниже	Обычно выше
Нестандартные процессы	Реализуются доработками	Можно заложить сразу
Модель данных	Зависит от устройства платформы	Проектируется под систему
Обновления ядра	Выпускает разработчик CMS	Организует команда проекта
Основной риск	Упереться в ограничения платформы	Получить дорогую систему, которую нужно постоянно поддерживать

 

Важный момент здесь не в том, какой столбец выглядит лучше.

Просто расходы и ограничения находятся в разных местах.

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

 

Классическая CMS

Теперь посмотрим на другой признак.

В классической CMS система управления и сайт обычно тесно связаны.

Редактор создает материал в административной части, а сама платформа знает, как его вывести на странице сайта.

Для большого количества корпоративных проектов это нормальная и понятная модель.

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

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

 

Headless CMS

В headless-подходе CMS занимается контентом, но не отвечает за то, как он выглядит для конечного пользователя.

Сайт получает данные через API и отображает их самостоятельно.

Представим обычную услугу. В CMS хранятся название, описание, изображение, документы и контакты.

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

Редактор при этом меняет услугу в одном месте.

Это и есть главное отличие headless: контент существует независимо от конкретной страницы или интерфейса.

Здесь полезна иллюстрация: CMS как единый источник контента, от которого данные получают сайт, мобильное приложение, личный кабинет и другой цифровой сервис.

Зачем отделять CMS от сайта

Такой подход особенно полезен, когда один и тот же контент нужен сразу нескольким системам.

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

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

При headless-подходе данные хранятся централизованно, а интерфейсы используют один источник.

Есть и вторая причина — свобода разработки пользовательской части.

CMS не диктует, как должен быть устроен frontend. Команда может развивать его отдельно и выбирать технологии под требования самого продукта.

Почему headless подходит не каждому проекту

Разделение системы добавляет новую сложность.

Теперь отдельно существуют CMS, frontend и API. Нужно продумать авторизацию, кеширование, предварительный просмотр материалов и работу при сбоях между компонентами.

Для большого продукта это может быть оправдано.

Для сайта компании из нескольких десятков информационных страниц — уже не факт.

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

 

Классическая и headless CMS: в чем разница

Критерий	Классическая CMS	Headless CMS
Связь CMS и сайта	Тесная	Разделены
Получение контента	Обычно внутри одной платформы	Через API
Один корпоративный сайт	Типовой сценарий	Возможен, но не всегда нужен
Несколько сайтов и приложений	Зависит от системы	Один из основных сценариев
Свобода frontend	Зависит от платформы	Выше
Техническая сложность	Обычно ниже	Обычно выше
Повторное использование контента	Возможно	Закладывается в архитектуру

 

Как эти подходы сочетаются

Здесь как раз становится видно, почему не стоит ставить готовую, собственную и headless CMS в один ряд.

Компания может взять готовую CMS и использовать ее в классическом варианте.

Можно взять готовую CMS только как систему управления контентом, а frontend разработать отдельно. Это уже готовая headless CMS.

То же самое с собственной системой. Она может быть частью одного сайта или отдавать данные сразу нескольким приложениям через API.

То есть у одного проекта могут одновременно быть характеристики «готовая» и «headless» или «собственная» и «headless».

Это не противоречие.

 

По каким еще признакам различают CMS

Готовая или собственная, классическая или headless — не единственные характеристики.

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

Коммерческие и с открытым исходным кодом

Коммерческая CMS распространяется по лицензии разработчика. Условия использования, обновлений и поддержки определяет поставщик.

У систем с открытым исходным кодом исходники доступны для просмотра и изменения в рамках условий конкретной лицензии.

Например, WordPress и Drupal относятся к open source. «1С-Битрикс: Управление сайтом» — коммерческий продукт.

При этом открытый исходный код сам по себе не означает, что проект получится бесплатным. Все равно остаются расходы на разработку, настройку, инфраструктуру и поддержку.

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

Это всего лишь один из параметров.

Облачные и на собственной инфраструктуре

Еще одно различие — где работает CMS.

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

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

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

Для корпоративных проектов этот вопрос часто становится важным уже на этапе требований к инфраструктуре и информационной безопасности.

 

Что в итоге

У CMS нет одной универсальной классификации.

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

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