Наверх

Проблема устаревания структур объектов в информационных системах

Время чтения: 16 минут
1
Проблема устаревания структур объектов в информационных системах

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

Илья Семенов (ilia.semenov@gmail.com), руководитель отдела программных разработок, D.Sc.T., Смарт Процессинг, Санкт-Петербург

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

По результатам опроса «Устаревание структур объектов в информационных средах», проведённого SPb CIO Club среди ИТ-руководителей, автор делает выводы, показывающие, насколько проблема актуальна на сегодняшний день.

Риск устаревания информационных объектов

Необходимость есть бедствие,

но нет никакой необходимости жить

с необходимостью.

Эпикур

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

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

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

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

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

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

Модель данных — один из важных параметров при выборе ИС

Кто хочет — ищет способ,

кто не хочет — ищет причину.

Сократ

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

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

●    открытость;

●    модульный/плагинный подход к расширению;

●    общие схемы хранения данных;

●    пригодность к использованию в разных от­­раслях;

●    встроенные средства разработки.

К недостаткам:

●    длительный срок внедрения и адаптации под предприятие;

●    единое хранилище, затрудняющее выработку отчетности;

●    потребность в значительных вычислительных ресурсах;

●    трудность синхронизации данных с другими ИС;

●    сложность с расширением системы после внедрения;

●    неполный охват типов бизнеса;

●    отсутствие возможности полностью описать все бизнес-процессы компании;

●    вся аналитика строится на многомерных OLAP-базах, суть которых состоит в том, что данные хранятся в реляционных таблицах, а это приводит к негибкости в системе запросов и построении отчетов.

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

Рассмотрим типы информационных объектов, с которыми должна работать ИС. Автоматизируемые объекты можно разделить на три типа: статические, динамические по горизонтали и динамические по вертикали.

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

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

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

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

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

Классическое представление модели данных в ИС

Высшая мудрость — различать

добро и зло.

Сократ

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

Отчасти эти намерения привели к эволюции систем хранения данных от иерархических к реляционным, а от реляционных к объектным, оперирующим понятиями объект, свойство, событие, связь. Правда, суть хранения данных в объектных системах всё та же, табличная, если речь не идет о действительно объектных или постобъектных СУБД.

Модель сущность-связь и её часто используемое реляционное представление наиболее распространены при построении ИС. Реляционная модель, обладающая мощным математическим аппаратом (реляционным исчислением и реляционной алгеброй), представляет собой уже привычный механизм для описания предметных областей в виде таблиц данных.

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

●    свои характеристики — для каждой сущности товара может быть определен свой собственный набор атрибутов;

●    свою структуру — товар может быть определен дополнительным набором множеств каких-либо данных и связей с другими сущностями объекта «товар» и другими объектами разных типов.

Отображение такого объекта не должно быть выражено одной, заранее определенной матрицей, а должно постоянно меняться, а значит, и матрица должна изменяться вслед за объектом, отражая его действительность.

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

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

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

Опрос «Устаревание структур объектов в информационных средах»

Противоположное излечивается

противоположным.

Гиппократ

Опрос проводился среди членов клуба ИТ-директоров SPb CIO Club. Основная цель — выявление статистики по устареванию структуры информации в ИС, полученной из реального опыта внедрения и модернизации.

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

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

Чуть больше опрошенных (81%) подтверждают, что помимо функций существуют неактуальные объекты или сущности, структура которых не актуальна в рамках текущей деятельности компании. Можно сделать вывод, что изменение структур данных влечет за собой необходимость изменить интерфейс и функции.

Интересно было узнать у респондентов, все ли данные, представляемые в их системах хранения, удовлетворяют табличным представлениям. Оказалось, что у половины (52%) данные хранятся в разных структурах, не только табличных. Это говорит о том, что в ИС объекты реальной предметной области пытаются хранить так, чтобы они примерно соответствовали аналогам. Вопрос только в том, какая модель данных для этого используется.

Кроме того, 62% опрошенных утверждают, что в их ИС есть данные, которые требуется детализировать, расширить, увеличить степень их уникальности, но в рамках имеющейся системы представления данных это невозможно. Этот показатель отражает гибкость ИС, большинство из которых фиксирует в себе статичное состояние предметной области и требует вмешательства вендоров для настройки под новые требования. Многие ИС позволяют изменять модель представления информационных объектов (например, настраивать атрибуты), и это подтвердили 90% опрошенных. Но только 35% отметили, что в их ИС есть возможность изменять модель представления каждой конкретной записи в БД индивидуально (например, настраивать индивидуальные атрибуты, свойства).

Подводя итог, отметим, что 45% ИТ-руководителей считают свою ИС гибкой в вопросе идентификации сущностей реальных объектов, с которыми работает компания, т. е. способной гибко описывать/настраивать объекты предметной области, а 55% считают свою систему негибкой. Немаловажно, что 90% ИТ-руководителей уделяют внимание вопросу модели хранения данных во внедряемых ими ИС. А это говорит о том, что руководителей интересует, как построена система изнутри.

Выводы

Начало — половина целого.

Пифагор

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

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

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

Для развивающихся компаний продукт, основанный на классической статической модели данных, не подходит, если его нельзя перенастроить. В таком случае информационные объекты пе­рестанут удовлетворять структурам, поведению, свойствам объектов предметной области. А это приведет к необходимости перестраивать систему.

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

Богатый набор инструментальных средств для проектирования ИС, основанных на реляционной алгебре, — очевидный выбор вендоров. Это пока единственно доступное и дешевое решение, которое целесообразно использовать с точки зрения экономики подрядчиков, — задумываться о быстром устаревании систем никто не хочет, это невыгодно. Однако конечные потребители ин­формационных продуктов, на мой взгляд, должны уже сейчас выдвигать требования к ИС, свя­занные с динамикой объектов. Статистика показывает, что проблема актуальна, 86% ИТ-руководителей подтвердили, что формируют списки доработок системы исходя из изменений внешней и внутренней среды. У 38% бизнес-процессы в компании меняются раз в год. При этом подобные изменения влекут доработки и полную переделку ИС, что подтвердили 43% ИТ-руководителей.

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

Многие компании позиционируют свои продукты по автоматизации документооборота и делопроизводству. На каких базах данных основываются их платформы? Как правило, на SQL-ориентированных. То есть документы режутся на плоские таблицы. А есть ли что-нибудь на рынке, что вписывается в понятие документ?

Для начала давайте вспомним определение документа. Документ — это материальный носитель с зафиксированной на нём в любой форме информацией в виде текста, звукозаписи, изображения и (или) их сочетания, который имеет реквизиты, позволяющие его идентифицировать, и предназначен для передачи во времени и в пространстве в целях общественного использования и хранения (федеральный закон № 77-ФЗ «Об обязательном экземпляре документов»). C информационной точки зрения документ — это совокупность атрибутов и их значений или набор пар ключ — значение.

Конечному пользователю представлять данные как документы привычнее и понятнее, чем представлять их как набор нарезанных реляционных таблиц. Если не рассматривать реляционный подход в качестве хранения документов, то на рынке не так уж мало платформ и технологий для работы с сущностями такого рода. Из самого простого те же xml- и json-форматы очень гибки для хранения документориентированных данных. Существует набор СУБД, предназначенных для этих целей: CouchDB, MongoDB, Redis, Riak, Berkeley DB и др. Каждая технология базируется на принципе описания произвольного документа, т. е. удовлетворяет определению федерального закона.

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

С автором можно связаться по адресу ilia.semenov@gmail.com

Источник: Intelligent Enterprise

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 1

Начало — половина целого - это по Пифагору. Но тут не более 10%. 

Чтобы прокомментировать, или зарегистрируйтесь