А.Немченко: Прошло 5 лет - текст актуален.
Единая информационная система, покрывающая все потребности университета, из коробки, от одного вендора, в мире не существует.
(Здесь, в скобках, отвечу евангелистам Microsoft, SAP, etc.: из ваших продуктов можно собрать нечто подобное, но это не будет ОДНА система. А то, что СБОР ваших продуктов окажется лучше и/или дешевле сбора других, не ваших решений, очень и очень сомнительно - чтобы ни говорили ваши маркетологи.)
Следовательно, то что в каждом университете мира присутствует целый зоопарк, несовместимых между собой программных продуктов и форматов хранения данных - это ЕСТЕСТВЕННО.
Очень рано, почти сразу после появления первых компьютеров в университетах, специалисты столкнулись с проблемой интеграции информационных систем. Пока этими, тогда новыми, электронными игрушками занимались физики и инженеры, они же их и решали по своему: на физическом, канальном, сетевом и пр. уровнях.
Скоро на этих уровнях все стабилизировалось, в индустрию пришли большие деньги - оказалось, что IT - это очень даже бизнес - нефть и оружие на вложенный доллар приносят меньше. Из ниоткуда возникшие корпорации, стремясь удержать клиентов и усложнить жизнь конкурентам, стали вводить свои патентованные форматы и стандарты, что еще усугубило стохастические — самопроизвольно стремящиеся к хаосу, процессы становления индустрии кодирования.
Использовать проприетарные и свободные программные средства стали совместно, ибо к первым уже успели привязаться, а вторые у неспециалистов долго вызывали смущение необычностью бизнес-модели распространения. Их раздавали, да и сейчас раздают, бесплатно. (Многие до сих пор не могут поверить, что хорошие, качественные вещи так вот просто отдают - бери и пользуйся. Спешу успокоить, неверующих в альтруизм: капитализм нашел, как получить своё. Более того, норма прибыли здесь еще выше, за счет более высокой производительности труда - в open source работают лучшие, и за счет более дорогой технической поддержки, ибо продукты более совершенны и сложны.)
Использование компьютерной техники и программных средств стало повсеместным и в первый ряд проблем вышел прикладной уровень. Реализация лозунга: "Больше программ хороших и разных" привела к тому, что ВСЁ стало несовместимо. Даже продукты одной корпорации не гарантируют совместимости. Бичом для клиентов (и новым источником прибыли для вендоров) стала несовместимость даже одних и тех же продуктов, но разных версий. Потребитель попал в ловушку - он должен платить и платить: каждый год за техническую поддержку, каждые пять лет за новую версию программных продуктов, количество и разнообразие которых растет.
Вместо того, чтобы развивать СВОЙ бизнес, потребитель программ поддерживает развитие IT-компаний - они его просто грабят.
С трудом поддерживая статус-кво или очень медленный рост производительности труда потребителей, корпорации прямо препятствуют прогрессу. Мы, потребители, остаемся один на один со своими проблемами. (Был, правда, шанс объединиться, хотя бы нескольким университетам и в рамках ассоциации решать их, но он, к сожалению, был упущен.)
Итак сегодня перед нами задача: в университете 5-10 больших и 20-30 малых информационных систем. Необходимость интеграции, кажется, уже очевидна всем. Какие есть реальные подходы?
Простые связи между системами типа "один к одному" по необходимости прорастали сами и, конечно, носили примитивный характер. Сейчас очевидно, что если такие связи спроектированы грамотно и используют стандартные форматы обмена - это хорошо. Специалисты называют такой тип взаимодействия автономных систем сервисами. Каждая система, как бы предоставляет другой системе сервис - передает ему свои данные для дальнейшего использования.
Схема зарождающихся связей через сервисы
Такая неразвитая сеть слабо связанных редким периодическим обменом (как правило односторонним) данными, характеризуется обособленными подмножествами конечных клиентов, группирующихся вокруг "своего" сервера и "своей" информационной системой.
Чем дольше длиться это обособление, тем сильнее отстает университет в целом от передовых в этом отношении организаций, по сути он просто деградирует - его сносит течением времени назад.
Схема развитой системы связей через сервисы "каждый с каждым"
Такая схема, даже эстетически выглядит безобразно, хотя здесь представлено только пять систем и только три из них имеют полный набор связей. Очевидно, что в этом хаосе вполне может функционировать организм большого университета такого, как МГУ или Бауманка - там хаос это норма. Однако для небольшого или среднего по размеру университета с компактным кампусом, такого как МГИМО, эта схема вряд ли оптимальна. Ее сложно поддерживать и контролировать ее из одного центра невозможно.
Схема связей через базу обмена данными
Элемент схемы с буквой К - означает коннектор, т.е. связующий программный модуль, специфичный для каждого вида связи между системами.
Пример
1. ФИО, факультет, группы студентов, срезы и пр. вводятся сотрудниками деканата в систему Деканат.
2. Через Базу обмена данными (БОД) эти данные эхспортируются в другие системы.
3. Текщую оценку преподаватели могут ставить в системе Электронный журнал, где ее могут видеть студенты и родители.
4. Если преподаватель проводит тестирование в системе LMS, результаты тестирования (оценки) через БОД эхспортируются в Деканат и в Электронный журнал.
Систем подлежащих интеграции по той или иной схеме, в МГИМО еще много, поэтому работы тому коллективу разработчиков, который сложился во время работы над этой системой, хватит на несколько лет.
