Создается впечатление, что интеграция, не прощаясь, уходит со сцены информационных технологий. Ни интеграционные серверы, ни брокеры не получили того всеобщего распространения, на которое рассчитывали. Не прижились. Или прижились, но не везде. И, во всяком случае, не стали той «серебряной пулей», о которой мечталось. Это относится и к внутренней интеграции, связанной с популярной аббревиатурой EAI (enterprise application integration). Это относится и к внешней интеграции с ее еще более известной и скандальной аббревиатурой B2B. (Хотя, говоря честно, отличие между ними не столь велико и в основном лежит в технической плоскости — прежде всего, в преодолении средств внутрикорпоративной защиты и способов разделения на своих и чужих).

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

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

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

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

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

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

Так зачем же нужна интеграция? Если рассмотреть идеальное состояние ИТ на предприятии и статический срез ее жизни, то, возможно, интеграция не так и нужна. Есть определенные задачи, которые надо решить с помощью ИТ либо потому, что иначе не получается, либо потому, что так дешевле, либо потому, что так захотелось владельцу или директору. Если все задачи решены, то все и довольны. Однако компания, ее бизнес, ее существование постоянно меняются. А ИТ уже настолько сильно проросли в бизнес, что вынуждены вместе с ним постоянно меняться, но — не могут. Получается, даже связав идеальную информационную среду предприятия, уже завтра придется ее перевязывать, то есть именно распускать и вязать заново. Да, возможно, сегодня все хорошо, но завтра финансовый директор попросит сделать заковыристый отчет, программисты поднажмут, и через несколько дней отчет будет готов. А еще через неделю исполнительный директор захочет другой отчет. И потянется — ИТ-отдел возненавидит финансового директора, а заодно и всех начальников, начнутся трения. Но ни ИТ-специалисты, ни директор не виноваты. Значит, что-то тут не так, и надо действовать по-другому.

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

Платформы и сервисы

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

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

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

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

Ни одна из существующих программных платформ не решает всех проблем. .Net не умеет работать на оборудовании Sun Microsystems и IBM. J2EE не очень ладит с приложениями, написанными на Коболе.

Маятник интеграции раскачивается от внутреннего уровня (брокеры объектных запросов, операционные платформы) до внешнего (порталы, корпоративные хранилища, Web-сервисы). Web-сервисы отличаются от традиционных Internet-приложений, как кино от застывшей фотографии. Если раньше мы только обозревали содержимое сайтов, то теперь хотим оживить Сеть, заставить ее двигаться и выполнять транзакции, причем со всеми необходимыми сервисами: безопасности, транзакционной целостности и др. Хорошая и красивая идея, призванная всех примирить и объединить. Но, к сожалению, и здесь идею растаскивают на отдельные несовместимые и малосвязанные стандарты. Беспокоит и другое. Интеграция с помощью Web-сервисов «схлопывается», превращаясь в интеграцию документов на основе XML, осовремененный вариант EDI.

Архитектура и стратегия

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

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

Стратегия тянет за собой архитектуру (и наоборот) — ведь стратегия представляет собой двигатель развития архитектуры. Без привязки к архитектуре стратегия остается красивым воздушным шариком, который легко парит в воздухе и, вообще говоря, бессмыслен. На мой взгляд, отличие ИТ-архитектуры от «просто архитектуры» состоит в том, что просто архитектура намного понятнее и легче. Здание чаще всего строится с нуля, а «здание» ИТ почти никогда: сегодня нет предприятий, у которых еще нет компьютеров и программ, поэтому архитектура ИТ и, в частности, архитектура программных систем, всегда вынуждена учитывать наследуемые системы. Наверное, не случайно архитектура SAP R/3 называется «ландшафтом». Ландшафт вынужден считаться с речкой, которая протекает по территории или с высящимися на горизонте горами.

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

Поскольку и стратегия, и архитектура — сложные и многоплановые понятия, для их описания полезно использовать эффект матрешки. Растерявшись от хаоса разноплановых и разноуровневых проблем, очень удобно выделить один уровень (одну матрешку) обдумать и описать его, а потом переходить к следующему. Можно возразить — есть прекрасная модель Захмана, изощренная модель Спивака, нечеткая модель TOGAF (The Open Group Architecture Framework), иерархическая глобальная модель PRM (Performance Reference Model) и очень сложная модель GERAM (The Generalised Enterprise Reference Architecture and Methodology). Возможно, я плохо искала, но мне не известен ни один случай полного описания архитектуры организации ни по одной из перечисленных моделей. Думаю, подобное описание займет многие тома и — как произошло с такими же пространными описаниями бизнес-процессов — станет совершенно бесполезным. Это, однако, не означает, что я предлагаю сложить руки и отказаться от какого бы то ни было описания архитектуры и формулировки стратегии. Краткое и понятное неспециалистам описание архитектуры помогает найти общий язык с руководством и акционерами, позволяет войти в ситуацию консультантам и новым сотрудникам — это самая внешняя матрешка.

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

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

Временная ось: направление (тенденции); завтра; сегодня; вчера.

Функциональная ось; это ось потоков работ, взаимодействия и регламентов: поставщики; клиенты компании; конкуренты компании; пользователи; ИТ-отдел.

Финансовая ось: стратегическое планирование затрат на ИТ; анализ эффективности ИТ; бюджетирование ИТ; учет затрат на ИТ.

Ось стандартов: международные стандарты; национальные стандарты; отраслевые стандарты; родственные стандарты; смежные стандарты; корпоративные стандарты.

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

ИТ как зеркало предприятия

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

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

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

Мне больше по душе представлять ИТ как параллельный виртуальный мир, отображающий предприятие в компьютерной электронной среде, повторяющий, определяющий, опережающий движения этой среды. Как его назвать? Предлагаю по аналогии с электронным бизнесом — электронное предприятие. Электронное предприятие должно представлять собой «живую модель» предприятия (evergreen alive), его «зеркало», которое практически без задержки повторяет все его движения.

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

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

Сначала необходимо описать бизнес-процессы предприятия. Существует множество методов описания бизнес-процессов — начиная более или менее подробными текстами и заканчивая IDEF, ARIX и UML. Проблема не в том, как их описывать, а в том, как сделать так, чтобы это описание соответствовало текущим бизнес-процессам в течение разумного периода времени. А именно: хотя бы чуть большего, чем время, в течение которого происходило описание. Беда в том, что, пока описывают бизнес-процессы, они успевают измениться. Поэтому добиться соответствия модели жизни очень непросто. А отказываться от их изменения лишь для того, чтобы не надо было менять модель, согласитесь, просто глупо.

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

Человеческая сущность ИТ и ее основные системы

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

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

Система безопасности

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

Отрадно, что именно эта сфера наиболее изучена и проработана. Здесь, с одной стороны, многое делается для повышения надежности защиты, а с другой — для упрощения доступа. Single Sign On — специальное программное обеспечение, позволяющее пользователю, один раз войдя в систему и введя пароль, получить доступ к различным защищенным приложениям без нарушения системы безопасности.

Именно в этой сфере в последние годы разработано немало стандартов.

  • ISO 17799. Предлагает широкий взгляд на управление информационной безопасностью. В качестве элементов управления рассматриваются технические и организационно-административные меры, направленные на обеспечение конфиденциальности, целостности, достоверности и доступности информации.
  • ISO/IEC 15443 «ИТ — Методики обеспечения безопасности — Основы обеспечения безопасности информационных технологий».
  • ГОСТ Р 50922-1996 «Защита информации. Основные термины и определения».
  • ГОСТ 28147-1989 «Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования».
  • ГОСТ Р 50739-95 «Средства вычислительной техники. Защита от несанкционированного доступа. Общие технические требования».
  • ГОСТ Р 51188-98 «Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство».

С 2004 года в России действует международный стандарт ГОСТ Р ИСО/МЭК 15408 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий».

Стандарты затрагивают различные аспекты безопасности.

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

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

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

Задумайтесь о том, чтобы построить систему безопасности не по отдельным программным системам, как обычно и делается, а по приведенным направлениям. Правда, добиваться соответствующего уровня безопасности в разных программных системах придется разными средствами. (Впрочем, в области аутентификации кое-что делается — Single-Sign-On.)

Система наименований

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

  1. Обеспечьте уникальность имени и не допускайте расхождений и интерпретации при построении соответствия имени и элемента именования.
  2. Учитывайте распределенную природу современных ИТ и необходимость администрирования подобной системы.
  3. Используйте иерархическую структуру имен, которая очень хорошо видна, например, в URL. При этом вовсе не обязательно иметь единый корень имен.
  4. Постройте естественное отображение сервиса каталогов на построенную в компании систему имен.
  5. Предусмотрите процесс связывания имен (с объектом, с элементом, с органом нашей сущности), а также разрушения связей.
  6. Не забудьте выделить разрешенные символы и создать общий словарь разрешенных символов.
  7. Разработайте краткую инструкцию по системе именований и доведите ее до всех сотрудников.

Система наименований позволит добиться серьезных выгод в процессе построения электронного предприятия.

Система обмена сообщениями

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

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

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

Система регистрации событий и уведомлений

Система регистрации событий тесно связана с системой обмена сообщениями. Сформулируем рекомендации, которым стоит следовать при ее построении.

  • Следует выбрать стандартную форму описания событий. Считается хорошим тоном делать ее читабельной, например, с помощью XML.<>
  • Необходимо обеспечить однозначность формулировки подписчиком интересующего его события.
  • Регистрировать следует только те события, на которые существует подписка, остальные не должны учитываться.
  • Необходимо предоставить потенциальным подписчикам возможность выбрать интересующие события из списка и по отдельным характеристикам.
  • Для событий, которые регистрируются в системе, должен быть предусмотрен широкий набор различных характеристик.
  • Необходим репозитарий типов событий, облегчающий построение разнообразных фильтров конечным пользователем.
  • В список событий полезно включить получение подтверждения подписчиков о поступлении информации о событии.
  • Следует обеспечить поддержку push-модели (система высылает сообщение о событии подписчику) и pull-модели (подписчик сам обращается к системе и просматривает данные по интересующим его событиям).

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

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

Несколько практических советов напоследок

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

А там — кто знает, что внутри у следующей матрешки?

Марина Аншина (Anschina@kbemos.ru) — руководитель ИТ-отдела компании «Профайн РУС», заместитель председателя правления фонда ФОСТАС (Москва).