Headless-архитектура информационной системы предприятия



Под термином «headless software» (англ. программное обеспечение без головы) подразумевается программное обеспечение, работающее без пользовательского интерфейса (например, веб-сервер или СУБД). Так же, в настоящее время набирают популярность так называемые «Headless websites» (англ. безголовые веб-сайты) — это сайты, как правило расположенные в облачной инфраструктуре, но при этом с пользователем напрямую не работают, а отдают данные пользовательским приложениям через программные интерфейсы.

В данной статье, применяя термин «headless», я хочу рассмотреть более широкое его определение — это не столько отсутствие пользовательского интерфейса у программного обеспечения, сколько возможное отсутствие «головного» сервера, то есть децентрализованная информационная система. Все части информационной системы при этом взаимодействуют между собой через программные интерфейсы (API), которые должны быть хорошо задокументированы и жестко унифицированы в пределах всей системы. Пользовательский интерфейс в этом случае может быть построен с помощью любой доступной или предпочтительной технологии — будь то веб-приложение на HTML и JavaScript через посредничество веб-сервера, мобильное или desktop-приложение, работающее через нативные для этих систем пользовательские интерфейсы.

Рассмотрим традиционную информационную систему небольшого предприятия (Рис. 1).

Рис. 1. Пример централизованной информационной системы

На первый взгляд, все выглядит нормально: пользуясь системой учета с единой базой данных, мастер смены указывает выработку продукции, кладовщик ведет учет прихода/расхода материалов, бухгалтерия на основании этих данных ведет бухгалтерский учет. Проблемы начинаются, когда автоматизируются какие-либо участки производства, или возникает потребность во внутреннем сетевом ресурсе — например базе знаний на wiki-движке (Рис. 2).

Рис. 2. Гибридная информационная система предприятия

Как видно на Рис. 2, части системы оказались изолированными, и этому есть несколько серьезных причин. Первая — все они работают с разными системами управления базами данных. Например: сервер 1С работает с СУБД Microsoft SQL Server, wiki-система базы знаний — с MySQL, система контроля доступа — с Firebird. Еще хуже дело обстоит с учетом подачи сырья и готовой продукции: контроллер, собирающий с них данные, передает их в систему управления технологическим процессом, которая может хранить данные в каком угодно виде, не исключая закрытый проприетарный или зашифрованный формат. Следующая причина — части системы могут находиться в разных сетях, причем одна подсистема может не иметь доступа к какой-либо сети. Пример: база знаний предприятия находится на веб-сервере, расположенном в сети интернет, но у мастера в цехе доступа туда нет (а пользоваться базой знаний необходимо). Обратный пример: директор предприятия хочет получать ежедневные отчеты о произведенной продукции на электронную почту, но автоматизированная система управления технологическими процессами не имеет доступа к сети интернет.

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

Для решения этих проблем наиболее целесообразно использовать headless-архитектуру информационной системы (Рис. 3).

Рис. 3. Пример headless-архитектуры

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

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

Не важно, на каком языке программирования написано ПО той или иной подсистемы, а также в каком формате данные передаются между ними. Единственное требование — формат, а также структура передаваемых данных должны быть согласованы между подсистемами. На данный момент наиболее распространенными форматами передачи структурированных данных являются XML и JSON — оба они представляют простые текстовые данные. Существует большое количество библиотек для работы с ними для различных языков программирования, так что использование именно этих форматов видится наиболее разумным.

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

Литература:

1. Норенков, И. П. Автоматизированные информационные системы: Учебное пособие / И. П. Норенков. — М.: МГТУ им. Баумана, 2011. — 342 c.
2. Смирнова, Г. Н., Сорокин, А. А., Тельнов, Ю. Ф. Проектирование экономических информационных систем / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. ― М.: Флинта, 2009. ― 512 с.
3. Фаулер М. Шаблоны корпоративных приложений. — М.: ООО «И. Д. Вильямс», 2016. — 544 с.
4. Headless computer // Wikipedia. URL: https://en.wikipedia.org/wiki/Headless_computer (дата обращения: 30.10.2017).