Благодаря способности объединять разнородные ресурсы и приложения в единое целое, метакаталоги становятся все более популярны.
По прошествии многих лет, в течение которых компании приобретали дополнительное программное и аппаратное обеспечение, стремясь увеличить свою производительность, многим стало понятно, что возврат от инвестиций сокращается. В итоге сейчас компании стараются добиться большей производительности от существующего оборудования и приложений, а не за счет реализации передовых технологий.
Эта тенденция создает благоприятные возможности для проектов реализации служб каталогов, причем постепенно они становятся приоритетными во все большем количестве организаций. Фактически последние маркетинговые исследования, проведенные компаниями IDC, Burton Group и Gartner Group, показывают, что свыше 60% американских предприятий планирует развернуть службу каталогов.
Одна из причин растущей популярности таких служб — способность каталога связать разнородное оборудование и приложения в единое логическое целое. Метакаталог объединяет разобщенные хранилища данных таким образом, что становится возможным управлять ресурсами и максимально использовать заложенный в них потенциал с учетом конкретного пользователя. Метакаталог - это часть архитектуры унифицированного каталога, которая демонстрирует важнейшие преимущества службы каталогов (см. врезку «Метакаталоги: есть ли прогресс?»).
Но прежде чем разбираться, что представляет собой это программное обеспечение, и начинать разрабатывать схемы для своей службы каталогов, очень важно проанализировать существующие системы и процессы, чтобы определить, какие именно преимущества можно ожидать от реализации проекта в области службы каталогов.
ОПРЕДЕЛЕНИЕ СФЕРЫ ПРИМЕНЕНИЯ
Что бы ни писали в своих рекламных брошюрах поставщики, вы не можете просто купить службу каталогов, установить ее и рассчитывать на то, что, как по волшебству, она выполнит все ваши желания. В первую очередь, это относится к архитектуре метакаталогов. Нет простого автоматического решения, которое эффективно выполняет сложные функции и поддерживает связи, необходимые метакаталогу.
Пытаясь понять, какая служба каталогов лучше всего соответствует требованиям вашей организации, сначала необходимо определить рамки проекта реализации каталогов, а также выяснить, какие именно элементы он должен содержать. Например, простая адресная книга, как правило, не дает возврата от инвестиций (Return on Investment, ROI) и какого-либо улучшения работы компании. Кроме того, без плана дальнейшего расширения проекта такого рода реализация каталога вряд ли принесет большую выгоду за исключением кратковременных преимуществ. Вместе с тем многие организации пока не готовы к осуществлению полномасштабной задачи создания метакаталога. Точное определение рамок проекта поможет вам выяснить, какая часть континуума службы каталогов отвечает требованиям вашей организации.
Проекты создания службы каталогов намного реже достигают своей цели, чем внедрение целевой технологии для решения конкретной технической проблемы или добавления конкретной функции к информационной системе. Положительный момент состоит в том, что трудности при реализации службы каталогов чаще всего возникают из-за некорректного определения цели, а не потому, что эта цель не достижима. Самое главное — прежде, чем браться за проект, вам следует тщательно сформулировать и документально оформить задачу, которую он призван решить.
Каталог в конечном итоге оказывается полезен благодаря широкому диапазону информации, которую он содержит, а также поддержке повсеместного доступа к ней. При подключении к нему дополнительных хранилищ данных новые связи и взаимоотношения между хранилищами перевешивают самоценность каталога, как такового. По этой причине самый важный аспект проекта создания каталога — его перспективы. Необходимо учитывать общее представление о бизнесе организации, ее цели, процессы и политику в той же, если не большей степени, что и технические аспекты проекта. Ошибка на данном этапе впоследствии обойдется намного дороже, чем любые авансовые инвестиции в материалы или затраты времени.
Традиционно, существующие каталоги предназначались для конкретного приложения, обычно изолированного от других приложений и серверов в рамках инфраструктуры ИТ. Это породило «узкоспециализированные процедуры управления», которым следовали по привычке для поддержания сложившегося статус-кво, что в результате привело к общему росту затрат на управление в большинстве систем инфраструктуры ИТ. Определение места вашего проекта в архитектуре унифицированного каталога (см. Рисунок 1) поможет устранить неэффективные решения, возникающие из-за наличия разрозненных «островков информации», за счет объединения или создания ссылок на эти ресурсы в метакаталоге либо применения другого централизованного механизма для связи хранилищ данных и управления ресурсами с учетом личности конкретного пользователя.
КОМАНДНЫЙ СПОРТ
Корректное определение рамок проекта службы каталогов предполагает сбор информации от всех подразделений, которые этот проект так или иначе затронет. Но как можно выбрать лучших представителей от каждого подразделения, если вы не определили рамки проекта?
Лучше всего сначала создать группу представителей основных отделов. В частности, проект службы каталогов требует равного участия как членов рабочих групп, так и технических специалистов. Такой репрезентативный список, не состоящий исключительно из технических специалистов, может оказаться полезнее для определения целей проекта с точки зрения задач компании. Если основные подразделения, например кадры и бухгалтерия, не будут задействованы в проекте, то он может породить еще больше разрозненных островков информации и потенциально лишь обострить проблемы, которые вы пытаетесь решить. Таким образом, крайне важно оставаться в рамках ограничений поддерживаемой технологии и в то же время тщательно следить за тем, чтобы не позволить ей определять ваши бизнес-процессы и операции. Как только вы создадите представительную группу, считайте, что дело сдвинулось с мертвой точки.
Прежде чем реализовать проект службы каталогов, крайне важно заручиться поддержкой руководства организации, прямо указав им на потенциальные стратегические преимущества в бизнесе, которые могут предложить эти службы. Если руководители понимают пользу каталогов в достижении целей, стоящих перед компанией, то бизнес-менеджеры по конкретным направлениям, скорее всего, будут стремиться применять их в своей непосредственной деятельности. Без такой поддержки проект реализации службы каталогов очень быстро погрязнет в политических дрязгах.
Еще одна важная задача — информирование группы, работающей над проектом службы каталогов, о преимуществах этой службы с концептуальной точки зрения. Некоторые из блестящих идей, касающихся технического применения, подаются людьми, которые отнюдь не являются техническими специалистами. Баланс между технической и функциональной точками зрения может породить творческие и яркие идеи.
Информирование членов группы предполагает разъяснение особенностей и достоинств различных каталогов, а также вариантов их использования на примере диаграммы общей архитектуры, такой, которая представлена на Рисунке 1. Сосредоточьтесь на стратегических преимуществах с точки зрения взаимодействия с потребителями, сотрудниками и партнерами, а не на технических или архитектурных деталях, при обсуждении которых у большинства членов группы взгляд становится отсутствующим. (Более подробную информацию о преимуществах службы унифицированного каталога см. «Как создается единый каталог« в майском номере «Журнал сетевых решений/LAN» за 2001 г.)
Чтобы добиться успеха при реализации службы унифицированного каталога, основу которой составляет метакаталог, предполагаемые результаты должны быть согласованы со стратегией и целями организации в ее конкретном бизнесе, причем все это необходимо тщательно задокументировать. Зачастую точки зрения членов группы не совпадают с целями организации. Одна из причин заключается в том, что менеджеры и отдельные сотрудники часто воспринимают задачи, стоящие перед компанией, намного уже, чем ее руководство. Создание представительной группы поможет выработать более широкий взгляд на ситуацию.
ПЛАН ИГРЫ
Следующий шаг — разделить стратегию, цели и задачи организации в области бизнеса на множество процессов, которые либо уже внедрены, либо развертываются. (Крайне важно понимать, какие процедуры уже существуют, чтобы вы могли представлять, как эти элементы взаимосвязаны внутри организации.) Затем следует определить процессы, которые могли бы быть связаны с системой унифицированного каталога и усовершенствованы с ее помощью.
Например, как добавляются данные о новом сотруднике в информационную систему организации? Где создается «досье» на нового сотрудника? В системе управления кадрами? В системе контроля продаж? В бухгалтерии? Хранится ли оно во всех этих разрозненных системах независимо или на основании единых стандартов, которые связывают вместе эти описания? Вносятся ли данные о взаимосвязях нового сотрудника с другими служащими, информационными системами и функциональными элементами по запросу сотрудника или они создаются и передаются на «пакетной» основе?
Следует рассмотреть и другие вопросы. В частности, как хранится и отслеживается информация о заказчике, когда в вашу организацию обращается новый клиент? И как компания организует и предоставляет информацию внутри и во вне, для потребителей и партнеров по бизнесу?
Непосредственная цель данной части проекта состоит не в решении и предупреждении проблем, а в понимании уже существующих процессов и взаимосвязей. Выяснив это, вы сформируете представление о том, насколько функциональные единицы или подразделения следуют бизнес-процессам и используют их в масштабах всей организации. Оно должно описывать формальные и неформальные функциональные взаимосвязи, а также содержать другие основные компоненты, которые необходимо учесть при проектировании и развертывании систем унифицированного каталога.
Здесь следует сделать одно замечание. Эти действия, скорее всего, поднимут политические вопросы, касающиеся проекта реализации службы каталогов. Различные подразделения и сотрудники поймут, что они приобретут либо потеряют от реализации проекта. Вы можете столкнуться с противодействием реформам, которое существует в любой организации, а также с тем, что, несмотря на наличие утвержденных правил, касающихся бизнес-процессов, какая-то их часть может не соблюдаться, а другая окажется устаревшей вследствие организационных изменений. Пересмотрите свои правила и убедитесь, что они адекватно задокументированы, а также определите, как они связаны с бизнес-целями и процессами, которые вы запланированы. Как только это будет сделано, вы можете определить приоритеты в соответствии с требованиями бизнеса, а не пытаться устанавливать их, следуя характеристикам конкретных продуктов, реализующих службы каталогов.
ТЕХНИЧЕСКИЕ ВОПРОСЫ
Помимо рабочих процессов и процедур важно учесть достаточное количество технических деталей. Первоочередное внимание следует обратить на то, какие хранилища данных могли бы быть добавлены в унифицированный каталог.
Хотя описание конкретных технических подробностей выходит за рамки этой статьи, важно отметить несколько основных моментов. Унифицированный каталог, такой, как показан на Рисунке 1, включает в себя метакаталог, куда входят различные каталоги управления и обеспечения, а также каталоги защиты. Метакаталог предлагает интегрированное представление об объектах и управляет взаимоотношениями между объектами во множестве доменов. Он также помогает распределению ресурсов и может поддерживать либо централизованное, либо распределенное администрирование.
Содержащиеся в нем каталоги защиты способны включать в себя информацию, касающуюся аутентификации, авторизации и аудита, а также системы сертификации (например, сертификаты PKI). К другим возможным элементам относятся накопленные данные о регистрации, специфические для конкретного пользователя соглашения об уровне сервиса (Service Level Agreement, SLA) и правила защиты.
Хранилища данных внутри отдельных каталогов (каталогов баз данных, специфических для приложения каталогов, внешних каталогов, внутренних каталогов, каталогов NOS и каталогов инфраструктуры) могут быть связаны между собой через метакаталог.
Процедуры, которые специалисты по производству документируют для потенциального управления системой унифицированного каталога, как правило, относятся к существующим хранилищам данных. Хотя некоторые сотрудники и не разбираются в базовой архитектуре, как правило, они могут указать по приложению, какие хранилища данных они используют в своей повседневной работе. Например, служащие отделов кадров, вероятно, не знают и не думают о том, что при обработке запросов работают с базой данных Oracle или SQL Server; они просто обращаются к ней, не интересуясь именем производителя этого программного обеспечения. Чтобы определить, каковы характеристики хранилищ данных и как они используются, создайте документ, аналогичный таблице «создать-считать-обновить-удалить» (Create-Read-Update-Delete, CRUD), которая обычно имеется в базе данных или в структуре, определяющий права доступа к файлам. Таблица CRUD должна включать в себя информацию о том, кто или какое приложение имеет право либо разрешение изменять хранилища данных и при каких обстоятельствах. Она должна также содержать характеристики хранилищ данных: размер, число записей, шаблоны использования и зависимость от других хранилищ.
Добавляйте информацию в таблицу CRUD до тех пор, пока ее не окажется достаточно, чтобы полностью охарактеризовать вашу среду. Но при этом старайтесь добиться ее максимальной простоты. При планировании внедрения каталогов хорошо бы детально разобраться в физической структуре хранилищ данных, но на данный момент в этом нет необходимости. Сейчас важно проиллюстрировать, как каждое из хранилищ данных связать с процедурами, к которым прибегают специалисты предприятия в своей повседневной работе, чтобы определить, нужно ли каждое конкретное хранилище добавлять в систему унифицированного каталога.
Этот анализ поможет установить приоритеты приложений и, как следствие, хранилищ данных, с точки зрения того, как и когда вы хотите интегрировать их в архитектуру системы унифицированного каталога. Помимо приоритезации хранилища данных следует упорядочить по типу каталога, который они поддерживают (например, внешний, внутренний, NOS, инфраструктура и т. д.) в контексте архитектуры унифицированного каталога (см. Рисунок 1).
Всю эту информацию можно добавить в документ, где описываются взаимосвязи между бизнес-функциями организации и дается общее представление о том, как работает организация. Диаграмма на Рисунке 2, к примеру, показывает, как каталоги специального назначения, каталоги PKI, каталоги электронной коммерции и каталоги NOS связаны с метакаталогом. С его помощью пользователи могут прозрачным образом получать доступ к таким ресурсам, как белые страницы, желтые страницы и электронная почта.
Диаграмма бизнес-процессов также показывает, как Lightweight Directory Access Protocol (LDAP) и Extensible Markup Language (XML) используются в системе. Она содержит правила Directory Enabled Networking (DEN), касающиеся предоставления, защиты, доступа и ресурсов. (DEN — это инициатива, направленная на распространение технологии каталогов для более эффективного управления отношениями между сетевыми ресурсами, приложениями, службами и пользователями.)
Документ вашей организации должен содержать пошаговое описание необходимых бизнес-процессов и диаграмму, которая их иллюстрирует. Проектная группа вместе с сотрудниками, которые предоставляют необработанные данные, могут проанализировать эту документацию с тем, чтобы определить, насколько точно она описывает бизнес-процессы компании. Это позволит создать объективную основу для принятия решения о том, как следует поступить с проектом службы каталогов.
ОБЪЕКТЫ В ДВИЖЕНИИ
Как только у вас появился документ, где описываются (в порядке приоритетов) процедуры, которым служба каталогов принесла бы пользу, эту информацию следует преобразовать в концептуальные приложения, работающие с данной службой. Для решения подобной задачи необходима помощь технических специалистов, понимающих, каким образом можно объединить каталоги для достижения требуемых функциональных результатов. Приложения должны соответствовать архитектуре унифицированного каталога, показанной на Рисунке 1. Не всегда есть возможность создать всеобъемлющую систему службы каталогов сразу. Таким образом, важно гарантировать, что первые шаги в намеченном проекте оставляли место для будущих разработок для всей системы каталогов с архитектурной точки зрения.
Чтобы получить ясное представление о концептуальной архитектуре, добавьте пошаговое описание того, каким образом каждый процесс и процедура должны соответствовать каталогам, включенным в нее. Это позволит вносить изменения, не ограничивая возможности будущих проектов, связанных с каталогами.
Преимущества такого решения выходят за рамки чисто технических аспектов проекта. Таким образом создается оболочка, с помощью которой компания сможет определить наиболее эффективные способы выполнения своих задач и спрогнозировать, какие еще усовершенствования могут быть сделаны. Все это требует огромной работы, но, так как службы каталогов затрагивают множество аспектов инфраструктуры ИТ и видимы многим пользователям сети, при возникновении проблемы, связанной с каталогами, может пострадать работа многочисленных пользователей, даже если базовая технология функционирует корректно.
Как ни парадоксально, тот же самый процесс позволяет сузить диапазон применения первоначального проекта, если это необходимо. Создавая документ, который касается всех бизнес-процессов, вы вправе спроектировать и определить приоритеты отдельных процессов, которые можно реализовать независимо в соответствии с общей архитектурой.
Такой подход позволяет добавлять в архитектуру новые проекты, касающиеся каталогов, что крайне важно. Если вы сразу пытаетесь решить все вопросы, возникающие в результате процесса исследования, то, скорее всего, это окажется невыполнимым. Вместе с тем, если при реализации первоочередных компонентов проекта вы не будете иметь в виду эти «вторичные» вопросы, то растеряете все преимущества службы унифицированного каталога.
БОРЬБА ЗА СОБЛЮДЕНИЕ БАЛАНСА
При реализации служб каталогов необходимо решить множество сложных технических задач. Но если созданию этой службы предшествует тщательный анализ и разработчики понимают, каким образом с точки зрения перспектив бизнеса можно использовать развитую технологию служб каталогов, то в конце концов все технические вопросы окажутся не такими уж сложными.
Конечная цель — создать масштабируемую, расширяемую систему на базе стандартов, которая может развиваться и меняться со временем по мере того, как меняются задачи, цели, стратегия и политика организации. Это требует достижения максимального баланса технических, коммерческих и производственных интересов.
Майкл Чакон — ведущий разработчик служб каталогов компании Netigy, которая предоставляет консультации по электронной инфраструктуре и профессиональные услуги в этой области. С ним можно связаться по адресу: michael.chacon@netigy.com.
Метакаталоги: есть ли прогресс?
Хотя метакаталоги составляют основу архитектуры унифицированного каталога, по своей зрелости их концепция превосходит продукты, реализующие службы каталогов.
Несмотря на появление интегрированных технологий, таких, как Lightweight Directory Access Protocol (LDAP), Extensible Markup Language (XML) и Universal Description, Discovery, and Integration (UDDI), реализация этих стандартов и спецификаций в существующих продуктах не гарантирует интероперабельности между решениями различных производителей. (Спецификация UDDI была создана для того, чтобы дать возможность компаниям найти друг друга и взаимодействовать посредством транзакций, осуществляемых через различные приложения.)
Например, если к продукту, реализующему каталог, можно обратиться через вызовы LDAP, то это отнюдь не означает, что он может полностью взаимодействовать с другой системой каталогов, поддерживающей LDAP. Требования соответствия схем двух продуктов могут препятствовать полной интероперабельности, если не приложить дополнительные усилия по разработке.
Положительный момент состоит в том, что, по мере совершенствования продуктов и рынка служб каталогов в целом, обеспечение истинной интероперабельности - в интересах всех производителей, которые стремятся выжить в условиях современного рынка. Но вам по-прежнему предстоит пройти нелегкий путь для получения эффективной открытой архитектуры службы каталогов. Если вы заинтересованы в реализации службы каталогов (или в продолжении реализации существующей службы), то необходимо следить за стандартами на каталог и поддержкой производителями этих стандартов в виде разработки конкретных продуктов.
Помните, однако, что метакаталог - концепция, а не продукт. Продукт, реализующий службу каталогов, станет метакаталогом только в том случае, если его используют определенным образом: например, как центральный каталог для управления объектами, а также как механизм для связи с другими каталогами в организации и синхронизации информации между ними. Самыми важными аспектами метакаталога являются правила и процедуры, которыми руководствуются при его развертывании, а не конкретный продукт, применяемый в данном проекте.
Ресурсы Internet
Консорциум OASIS занимается разработкой спецификаций на интероперабельность для расширяемого языка разметки Extensible Markup Language (XML). Более подробную информацию об OASIS можно найти по адресу http://www.oasis-open.org.
Информация от Directory Enabled Networking (DEN) предоставляется по адресу: http://www.dmtf.org. Подробные данные о Directory Interoperability Forum организации Open Group размещаются на Web-сайте http://www.opengroup.org.
Детальная информация о спецификации Universal Description, Discovery, and Integration (UDDI) расположена по адресу: http://www.uddi.org.