Невыносимая тяжесть монолитной КИС

Ссылки сюда (2) →

Автор

Михаил Заборов, руководитель направления «Торговые сети» компании «Заказные ИнформСистемы (CustIS)»

Сложность — главная проблема информационных систем

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

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

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

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

Это объективный процесс: в теории проектирования информационных систем давно известно, что сложность вообще присуща программному обеспечению, она является неслучайным его свойством и вызывается четырьмя причинами сложностью реальной предметной области, из которой исходит заказ на разработку; трудностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем. Сказанное выше остается справедливым и во времена ERP, SOA и прочих трехбуквенных сокращений.

По мнению Гради Буча, основные эффективные приемы борьбы со сложностью систем таковы: абстрагирование, декомпозиция и инкапсуляция. В нашем случае это означает, что когда управлять системой как единым целым становится невозможно, мы вынуждены разделить систему на взаимодействующие части, инкапсулировав (скрыв) детали внутри этих частей. Можно констатировать, что по сравнению с монолитной системой сложное многокомпонентное решение окажется менее эффективным при выполнении отдельных функций, но зато приобретет возможность дальнейшего развития, сохранив управляемость и надежность.

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

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

Хроника объявленной сложности (история из жизни)

Несколько лет назад одна компания, успешно развивающая бизнес и быстро растущая, решила избавиться от множества небольших ИТ‑систем, которые исторически составляли ее информационную среду. Это множество должна была заменить одна большая (всеобъемлющая) корпоративная система. Стратегия соответствовала мейнстриму на ИТ-рынке того времени.

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

Создание новой информационной системы началось со справочников. В современной терминологии это называется — системы управления мастер-данными (MDM). Затем в рамках единой системы стали добавляться функциональные компоненты. Замена старых систем выполнялась поэтапно в режиме «бережного» внедрения. Новый функционал создаваемой системы обеспечивал преемственность бизнес-процессов компании. Затраты на создание подсистем, заменивших старые разрозненные системы, составили десятки человеко-лет.

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

Проблемы разделения ответственности

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

Чтобы не терять высокой производительности, от которой зависит успешное течение проекта, приходится на ходу проводить реорганизацию, так чтобы группы ИТ‑специалистов, продолжая работать над частями единой системы, были относительно автономны и независимы.

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

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

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

Например, группа, обнаружив подходящий общий справочник, начинает модифицировать его в целях своей локальной задачи: вводят новые поля, которые используют только им одним известным способом. Другие команды подхватывают и, исходя из своих соображений, интерпретируют появившиеся данные. Следствием такой «точечной адаптации» коллективно используемых данных ­станет непредсказуемое поведение системы.

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

Система исподволь расползается. Пытаться останавливать разработчиков «палкой» регламентов — дело ненадежное и неблагодарное. «Человеческий фактор» изощреннее любых организационных запретов.

Непредсказуемые последствия модификаций системы

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

Никто уже не понимает, почему система так работает. Как в прецедентном праве: приходится полагаться не на архитектуру системы, а на случаи — правила обхода «граблей». Однако правила типа «туда не ходи, сюда ходи» со временем устаревают, и уже только отдельные старожилы проекта сохраняют знания о том, что «грохнется», если «пошевелить в этом месте».

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

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

Проблемы с ИТ-персоналом заказчика

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

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

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

Передача знаний и обучение хронически отстают от актуального состояния системы из‑за ее возрастающей сложности.

Проблемы производительности

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

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

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

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

Модернизировать программные технологии. Этот вариант мы рассмотрим в следующем разделе.

Проблемы модернизации технологий у заказчика

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

Модернизировать монолитную систему по частям не получается — приходится или разом заменять ее, или оставлять все «как есть».

Рано или поздно любую систему захочется модернизировать и по функционалу. Но в монолитную систему нельзя встроить решение типа Best Of Breed (лучшее в своем классе), которое бы заменило часть функционала старой системы. Придется менять систему целиком или существенно перестраивать ее архитектуру, что сильно осложняется описанными выше проблемами.

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

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

Приемы эффективной борьбы

Очень важно вовремя распознать, что КИС достигла деструктивного уровня системной сложности и что процесс ее создания и/или эксплуатации начинает выходить из‑под контроля. На наш взгляд, для этого достаточно зафиксировать проявление хотя бы одного — любого — из приведенных выше признаков.

Еще одно проявление достигнутого предела сложности монолитной системы — ее «обрастание» системами‑сателлитами. Поскольку развивать основную систему становится сложно, новые процессы реализуются «сбоку» в виде небольших «подпорок». Чем раньше будет осознано, что проблемы такого рода начались, тем больше вероятность, что компания сможет перестроить архитектуру и продолжить развитие системы, свободное от «вериг» излишней сложности.

Конечно, лучше с самого начала не наступать на эти грабли. Но в том‑то и беда, что проблемы сложности накапливаются постепенно и проявляются тогда, когда уже невозможно отступить и начать проект заново.

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

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

Оптимальное деление системы на части с точки зрения функционала. Нужно резать систему по автономным (относительно независимым инкапсулированным) частям предметной области.

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

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

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

Хотя мы здесь и попытались дать конкретные рекомендации по переходу от монолитной к многокомпонентной ИС, они не являются абсолютными. Декомпозиция системы — это ис­кусство. Это означает, что принципиально невоз­можно формализовать процесс формирования архитектуры многокомпонентной системы. Очень многое здесь зависит от мастерства кон­кретного архитектора. Таких людей очень немного. Кто они и как их выбирать, подробно описано в статье В. Рахтеенко «Проводники в джунглях системной сложности» (Intelligent Enterprise № 18/2008).

Награда — возможность развития системы

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

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

Для преодоления этого кризиса бизнес должен изменить парадигму управления ИТ и перейти от одного проекта к программе проектов. Неизбежное увеличение расходов на управление и вовлечение новых ресурсов — это плата за переход к многокомпонентной информационной системе, за сохранение управления и возможность ее дальнейшего развития одновременно по нескольким направлениям (фронтам), а в итоге — плата за достижение новой эффективности бизнеса.

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

Примечание

---

Репликация: База Знаний «Заказных Информ Систем» → «Невыносимая тяжесть монолитной КИС»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».