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

Управление в режиме реального времени

Управление бизнесом на основе устаревших данных считается сегодня нормой, и бизнес-пользователи не ставят перед ИТ задачу обеспечения систем поддержки принятия решений данными в реальном времени. И дело не только в привычке — построение таких систем традиционным образом будет существенно дороже возможного выигрыша, хотя еще на заре создания сложных информационных систем академик В. М. Глушков отмечал важность управления в режиме реального времени. Однако в этой области особых успехов пока не достигнуто, а о влиянии полноты и оперативности предоставления информации на качество принимаемых решений регулярно говорится практически в каждой работе об управленческих процессах.

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

В архитектуру всех современных ИСКП заложены как минимум две операции, которые вносят задержки, мешающие построению систем реального времени: загрузка данных из транзакционных систем в хранилище данных и извлечение данных для анализа. В большинстве случаев хранилища имеют сложную структуру с множеством витрин данных, которые могут быть разделены по нескольким СУБД. Существующие технологии извлечения, трансформации, очистки и хранения данных позволяют уменьшить задержки, но имеют приемлемую стоимость и сложность только для масштабов от суток до часов, а при приближении к настоящему реальному времени их стоимость растет экспоненциально.

Таким образом, технологические и архитектурные ограничения в сочетании со стоимостью и трудоемкостью реализации создали третий информационный барьер на пути к эффективному решению задач управления в реальном времени (первый и второй информационные барьеры, связанные с ограничением человеческих возможностей при решении возрастающего количества управленческих задач, описал еще Глушков). Наиболее существенная, но безуспешная попытка преодолеть этот барьер была предпринята в период с 2001 по 2005 год, когда аналитики Gartner сформулировали подходы к созданию предприятия, действующего в режиме реального времени — Real-Time Enterprise (RTE) [1]. Однако к реализации этой идеи подключились только производители аппаратного обеспечения, наладившие выпуск различных конвергентных решений, исключающих некоторые технические точки возникновения задержек. В области прикладного ПО находящаяся на пике популярности сервисная архитектура не позволила тогда разглядеть, что в ИТ-архитектуре барьеры не снимаются.

Были предприняты попытки в комплексе описать условия и подходы к построению предприятия реального времени с учетом всех его аспектов: оргструктуры, бизнес-процессов, информационных систем. Например, Микаэл Хугос в части информационной системы сделал ставку на сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA). В результате практические шаги по внедрению на предприятиях элементов сервисной архитектуры еще более усугубили проблему достижения реального времени, заметно усложнив ИТ-ландшафт.

Видя все эти безуспешные попытки в полной мере реализовать управление в реальном времени, аналитики Gartner скорректировали свое определение RTE, включив фразы «последовательное уменьшение задержек» и «только для критичных бизнес-процессов», и при этом уточнили, что настоящий режим реального времени асимптотически недостижим, однако инновации в области техники и технологии потенциально могут улучшить ситуацию.

Сегодня наконец-то появились реальные способы преодолеть барьеры на пути к предприятию реального времени и модернизировать саму парадигму ИСКП. Технология in-memory [2] и СУБД на ее основе, например SAP HANA, коренным образом меняют ситуацию и делают возможным построение настоящего предприятия, управляемого в режиме реального времени, — RTE 2.0 [3, 4]. Декларируемое улучшение производительности в 100–10000 раз и почти десятикратное уменьшение объемов данных полностью оправдались при практическом применении. Кроме того, благодаря конвергентному подходу и виртуализации значительно упростилась инфраструктура.

Очевидно, что проблема сложности порождена решениями уровней СУБД и логической архитектуры. И начало всех проблем лежит в реляционной модели СУБД, положенной в основу почти всех нынешних информационных систем. Поэтому сегодня, скорее всего, мы находимся не просто перед лицом новых технологий (in-memory, NoSQL и т. п.), а на пороге смены самой парадигмы построения информационных систем управления предприятием. Похоже, мы оказались свидетелями кардинального изменения взглядов на ИТ, о чем еще в 1975 году предупреждал Глушков, отмечавший, что появление оперативной памяти объемом 1010 –1012 байт полностью изменит взгляды на архитектуру и ОС.

Что же мешает применить СУБД in-memory и построить информационную систему предприятия, управляемого в режиме реального времени?

Проблема первая — функциональная избыточность платформ. Согласно хорошо известному закону, сформулированному кибернетиком Уильямом Эшби, сложность системы управления должна соответствовать сложности управляемой системы; избыточная сложность системы управления не добавляет преимуществ при управлении объектом. Однако большинство ИСКП построены на решениях, уже созданных для разнообразных применений в различных отраслях промышленности, — это платформы таких производителей, как SAP, Oracle, «Парус», «Галактика» и др. Изначально это действительно было благом — слегка подстроить систему для конкретного предприятия было выгоднее, чем создавать новую. Но со временем накопление различных «лучших практик» и развитие модулей существенно усложнили платформы — сегодня при внедрении таких систем основные усилия уходят на изучение предлагаемых стандартных решений и их приведение к нуждам конкретного предприятия. Наш собственный опыт, а также опыт партнеров, обнародованный на конференции «Стандарт SAP. Мифы и реальность», свидетельствует о том, что преднастроенные решения лишь на 40–60% соответствуют действительным потребностям предприятий. Оценив соотношение стандарт/нестандарт, например, при внедрении систем SAP, мы пришли к выводу, что применение таких решений заставляет предприятие следовать определенным подходам к ИТ-архитектуре, а это, как правило, сильно усложняет архитектуру. Историческое развитие уже привело поставщиков ИСКП к сложному многокомпонентному интегрированному ландшафту, поэтому данный подход только отдаляет от предприятия реального времени.

Проблема вторая — облака. Облачные технологии считаются сегодня самым современным и эффективным направлением развития информационных систем. В поисках новых способов заработать поставщики ИТ-решений предлагают предприятиям переносить в облако их бизнес-процессы, а чтобы сохранить целостность бизнес-модели, предлагается архитектура «гибридное облако». Однако на практике все это приводит к еще большему усложнению ИТ-ландшафтов и появлению специальных решений, отслеживающих целостность данных при исполнении бизнес-функций в облаке.

Свертывание

Анализируя RTE с помощью методологии анализа и прогнозирования систем как продуктов научно-технического прогресса (ТРИЗ), можно утверждать, что на современном уровне развития ИСКП усилия необходимо направлять не на улучшение текущего подхода к их совершенствованию, а на создание нового. Кроме того, наиболее выигрышная стратегия развития — это свертывание, состоящее в устранении из системы части ее элементов вместе с их излишними функциями и другими известными и неизвестными недостатками и распределении полезных функций среди оставшихся элементов системы. Полностью свернутая информационная система для среднего и малого бизнеса исчезает — она заменяется облачными бизнес-сервисами, а все вопросы, связанные с ИТ, в этом случае отпадают.

Крупные предприятия не могут полностью уйти в облако, а частичный уход только усложняет управление гибридными бизнес-процессами, в дополнение к традиционным. Поэтому для крупного предприятия актуально свертывание путем уменьшения числа компонентов ИТ-архитектуры с сохранением функциональной полноты для бизнеса. Идеально свернутая система должна работать с одной единственной базой данных, и эта база должна целиком размещаться в оперативной памяти. На логическом уровне это исключает все перегрузки и промежуточные сервисы, а на физическом — задержки между серверами базы данных и серверами приложений, так как в решениях категории in-memory прикладной код доставляется к данным, а не наоборот. На аппаратном уровне снижаются требования к дисковым ресурсам и средствам виртуализации, которые сами по себе съедают сегодня 10–20% производительности.

Если распространить свертывание на уровень системного ПО, то очевиден наиболее выигрышный вариант — создание связки «специализированная ОС и СУБД in-memory». В этом случае сложной остается только бизнес-модель и архитектура приложений, исполняющих бизнес-процессы, а все остальные превращаются в простые однокомпонентные решения.

В итоге, в соответствии с законами диалектики, происходит возврат к простоте систем, с которых и начинались ИСКП, но с сохранением всех функциональных наработок прошедшего периода.

«Мудрое» предприятие

Как свертывание отразится на бизнес-уровне? Определенные ожидания здесь связаны не только с повышением скорости выполнения бизнес-операций и получения аналитики реального времени, но и с изменением подходов, привычно учитывающих сложности ИТ-архитектуры. Однако проблема в том, что в этом случае необходимо полное перепроектирование бизнес-моделей и методологии, а значит — и прикладных решений. Например, подход in-memory позволяет перейти от каскадного закрытия отчетного периода в конце месяца к мгновенному оперативному закрытию, и для этого в первую очередь необходима новая методология учета.

Как бы то ни было, но в простой и быстрой ИСКП становится возможным построение самообучающихся адаптивных систем принятия решений, способных делать предсказания будущего на основе оперативной информации. Именно это отличает «мудрое» предприятие от «умного». Первое знает, что будет, и заранее готовится к этому, в том числе активно создавая желаемое будущее. Не случайно в последние годы появляются различные системы предсказательной аналитики (Predictive Analytics), многие из которых реализованы с использованием технологий in-memory.

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

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

***

Диалектический взгляд на текущее состояние крупных информационных систем позволяет утверждать, что сегодня мы находимся в процессе смены парадигмы, и наиболее вероятная линия развития, обеспечиваемая технологией in-memory, состоит в свертывании. Это позволит создать информационную систему управления предприятием в режиме реального времени, однако для того чтобы получить максимальную отдачу от технологии, необходима переработка подходов как на уровне бизнес-моделей, так и на уровне программно-аппаратных компонентов. Рынок информационных систем для RTE 2.0 еще не сложился, и зрелых решений здесь нет, поэтому развертывание таких систем может стать наиболее благоприятным направлением для приложения усилий и для инвестиций в контексте достижения технологической независимости.

Литература

  1. The Gartner Definition of Real-Time Enterprise. COM-18-3057, 01.10.2002. URL: http:// www.gartner.com (дата обращения: 18.09.2015).
  2. Plattner H. A Course in In-Memory Data Management: The Inner Mechanics of In-Memory Databases // Springer Heidelberg, 2013.
  3. Управление жизненным циклом информационных бизнес-систем. Real-time Enterprise 2.0.: сб. ст. / Под ред. Р.Д. Гимранова. — СПб, Сургут, 2014.
  4. SAP HANA. Технологическая платформа для решения современных бизнес-задач: сб. ст. / Под ред. Б.М. Коцовского, Р.Д. Гимранова — М., 2015. — 128 с.

Ринат Гимранов (gimranov_rd@surgutneftegas.ru) — начальник управления ИТ, «Сургутнефтегаз» (Сургут).