База знаний как ключевой элемент управления Enterprise-архитектурой международного аэропорта «Шереметьево»
Представьте себе, что вы летите с отдыха с пересадкой, и вот в транзитном аэропорту вашему самолету сначала не дают посадку, затем вы тусите пару суток в разных очередях, никто ничего не понимает, вам обещают вылет через 2 часа, но снова и снова переносят. Наконец, измотанный и уставший после отпуска, вы прилетаете в свой город и узнаете, что ваш чемодан улетел в кругосветку. Представили? А вот пассажирам, которые оказались в лондонском Хитроу 28 марта 2008 года и представлять не надо.
Коллапс продолжался больше недели после открытия нового терминала аэропорта. Поскольку Хитроу — ключевой европейский транспортный узел (в аэропорту каждые 45–50 секунд взлетают и приземляются самолеты), багажный кризис вызвал проблемы по всей Европе и даже по миру, а потерянные чемоданы развозили хозяевам еще 2 месяца.
Эта история в авиаиндустрии послужила поводом для множества уроков. И произошло все, в том числе, и из-за ошибок при трансформации ключевых процессов аэропорта. О том, как сегодня строится управление Enterprise-архитектурой международного аэропорта «Шереметьево», и какое место в ней занимает база знаний, рассказал Юрий Золотых, главный эксперт службы цифровой трансформации аэропорта, в рамках конференции TEAMLY.
Юрий Золотых, главный эксперт Службы цифровой трансформации АО «Международный аэропорт Шереметьево»
Если ваш бизнес мал…
… это не значит, что наработки крупных компаний вам не подходят. По словам спикера, проблемы построения архитектуры схожи и в среднем, и в крупном бизнесе.
У международного хаба, конечно же, есть своя специфика, главным образом потому что самолеты не умеют просто так зависать в воздухе в случае проблем. Аэропорт — пересечение множества бизнесов: это авиакомпании, обслуживающие организации, магазины и кафе, грузоперевозчики, представители госслужб и т.д. У многих из них существуют свои информационные системы, многие из которых должны быть встроены в единую архитектуру.
В такой сложной системе база знаний играет ключевую роль, потому что вся архитектура должна быть в этой базе, как минимум, описана.
Для этого, как правило, сначала разрабатывают онтологию — иерархический способ представления понятий и их связей.
Enterprise-архитектура
Методология TOGAF, которая сейчас является де-фактостандартом описания Enterprise-архитектуры, изначально предлагает многомерный подход. Архитектурный 3D континуум означает охват всей функциональной структуры, процессов и архитектурных доменов. И все это должна объединять база знаний.
Всегда есть соблазн пойти по пути упрощения: вместо создания единой базы знаний начать с маленьких баз отдельных подразделений, но объединить их потом в одну корпоративную базу знаний будет в разы сложнее. Один и тот же процесс может задействовать несколько совершенно разных подразделений, а инструкции к ним могут оказаться буквально на разных языках.
Пример:
Для того, чтобы вы без проблем совершили перелет и получили свой багаж в аэропорту назначения, должны четко взаимодействовать подразделения и службы нескольких компаний.
Вы зашли в аэропорт с чемоданом, сдали его в багаж, а через несколько часов забрали его уже в аэропорту прилета. Вот что при этом происходит:
досмотр на входе в аэропорт (служба безопасности аэропорта);
регистрация пассажира и багажа (авиакомпания или служба аэропорта);
досмотр на входе в «чистую зону» (служба безопасности аэропорта);
сортировка багажа (багажная система аэропорта вылета);
предоставление услуг маломобильным пассажирам, если это требуется (службы аэропорта);
доставка пассажиров на борт воздушного судна (хендлинг аэропорта: подача автобусов, трапов, телетрапов);
погрузка багажа на борт (хендлинг);
перелет (авиакомпания, аэропорт вылета и аэропорт прилета обмениваются информацией о пассажирах и багаже);
выгрузка и сортировка багажа (хэндлинг аэропорта прилета уже знает, чей багаж прилетел и куда он должен дальше следовать);
доставка пассажиров в терминал (хэндлинг аэропорта);
выдача багажа пассажиру (аэропорт).
Если вы следуете с пересадкой, или ваш рейс задерживается, например, по погодным условиям, то и ваш багаж, совершая не менее «увлекательное» путешествие между терминалами, попадает на склад, пока вы ждете посадку…
Конфликты инструкций могут привести к фатальным ошибкам. Да даже мелкие неприятности нам ни к чему.
Вот тут нам и помогает единая база знаний и онтология. Главное отличие онтологии от простого (плоского) словаря в том, что она позволяет определять отношения между терминами, причем, делать это не только в одной предметной области, но и соотносить между собой термины из разных предметных областей. Используя такой подход, мы можем состыковать в единый процесс подпроцессы, описанные в разных нотациях, если это необходимо или то требует специфика разных подразделений.
Теперь у нас появляется универсальный переводчик с языков разных профессий, а диаграмма «сущность — связь» позволяет объединить процессы всех участников и обеспечить непрерывность и непротиворечивость модели.
Вот визуализация схемы графовой базы данных Neo4j — фрагмент Enterprise-архитектуры, включающий всего 8 типов сущностей и пример решения простой задачи.
Например, мы модифицируем алгоритм обработки багажных сообщений двух типов: сообщений о регистрации (BSM) и сообщений об обработке (BPM) багажа и хотим знать, какие системы и интеграции между ними это может затронуть.
В нашем случае эти две сущности передаются в 26 интеграциях. Добавляем на схему системы-источники и системы-получатели. Это 17 информационных систем. Полученная схема содержит 91 связь.
И это лишь две простые с виду сущности. Кстати, именно из-за проблем в интеграции багажных систем и возник коллапс в Хитроу.
Вот схема текущей Enterprise-архитектуры с точки зрения интеграции информационных систем, в которых регистрируются сущности — архитектурные артефакты.
Использование графовой СУБД обусловлено необходимостью визуализации сложных запросов в отношении элементов архитектуры. Построив нужную схему, мы можем перейти с нее в базу знаний и получить актуальное описание для любого архитектурного артефакта или перейти непосредственно в систему-источник.
Наиболее часто используемый сценарий поиска информации относительно работы Enterprise-архитектуры выглядит так:
Найдя интересующий вас термин в словаре, вы легко можете найти связанные с ним сущности.
Уточняете, в каких информационных системах найденные сущности учитываются (регистрируются, модифицируются).
Далее, в зависимости от решаемой задачи, вы можете перейти к интеграциям между информационными системами, к бизнес-процессам или же непосредственно к документам — технологиям, в которых описаны процессы.
Если в базе знаний нет онтологии, а значит, невозможно указать контекст, в котором вы формируете запрос, то вам будет крайне сложно найти нужную информацию, даже если она есть в базе знаний.
Важные аспекты внедрения
Не стоит пытаться сразу объять необъятное. Можно упростить задачу построения Enterprise-архитектуры, например, до следующей последовательности:
Классифицируем объекты предметной области и тем самым выделяем сущности, которые будут элементами архитектуры, т.е. архитектурными артефактами;
начинаем ведение реестров сущностей, устанавливаем связи между ними;
разрабатываем и анализируем архитектурные схемы;
детализируем — в зависимости от решаемых задач расширяем атрибутивный состав артефактов, добавляем новые сущности и связи. Например: описываем функции информационных систем, состав интеграции и т.д.
База знаний в Enterprise-системе нужна всем, а значит… никому!
Все мы знаем эту особенность человеческого восприятия, когда нечто общее пускается на самотек в надежде, что у кого-то другого есть больше времени, сил, ресурсов, чтобы поддерживать всю работу. Если вы в процессе внедрения будете игнорировать аспекты охвата и непрерывности, то скорее всего ваша база знаний начнет деградировать — данные и знания в ней будут становиться неактуальными и фрагментарными.
Рекламная пауза
Посмотрите, какие фичи появились в осеннем обновлении нашей платформы для совместной работы и управления знаниями, документами и задачами TEAMLY. Для управления задачами, документами, целями и спринтами подойдут «умные таблицы» с двумя видами отображения: табличными и канбан. А текстовую рутину можно отдать на откуп AI. Улучшенные настройки прав позволят еще эффективнее работать с платформой внутренним и внешним пользователям.
