Сетевой журнал: галерея ИТ-проектов


Город-Инфо: портал - это архитектура



задача:
Корпоративный веб-портал
другие решения:
Сервокомп: решение, адекватное задаче





 

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

Корпоративные Web-порталы – одно из основных направлений деятельности компании. Ее гордостью является портал Тюменской нефтяной компании (ТНК), которым пользуется сейчас около 3 тыс. человек – практически вся ТНК. Другой крупный (и один из самых интересных с точки зрения разработчиков) проект, в котором применялась портальная технология, "Город-Инфо" выполнила для Государственного таможенного комитета (ГТК) РФ. "Город-Инфо" активно работает и с предприятиями среднего размера, для которых строит различные функциональные приложения в портальной архитектуре – CRM, логистические системы и т.п.

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

Начинаем со справочника
Итак, прежде всего строится каталог пользователей. Он фиксирует, кто и каким образом будет работать с портальными сервисами и приложениями, и в дальнейшем служит фундаментом для развития портала. Технически это каталог, поддерживающий стандарт LDAP; конкретная реализация, с точки зрения "Город-Инфо", неважна, но чаще всего используется Microsoft Active Directory или Netscape Directory Server. Не исключено, что в компании уже есть такой каталог (Active Directory сейчас внедряется очень активно); если же его нет, он должен быть создан. Понятно, что продуманная структура каталога исключительно важна – его неправильная организация способна привести к серьезным проблемам с приложениями, которые будут работать в портале. "Город-Инфо" предлагает следующее решение. Каталог условно делится на две части. В первой помещается информация о физических лицах: скажем, Вася Пупкин, его внутренний телефон, дата рождения, состоит в таких-то группах – и ссылки на соответствующие группы. Отметим, что эта часть прекрасно работает в качестве телефонного справочника компании (именно поэтому каталог пользователей называют еще справочником), так что фирмы после построения каталога обычно перестают печатать свой внутренний справочник и переходят на Web-доступ. Вторая часть каталога содержит информацию о группах. В первую очередь она отражает формальную организационную структуру предприятия (иерархию подразделений) и роли сотрудников в этой структуре. Роль в большинстве случаев полностью определяется подразделением и должностью, а сама, в свою очередь, определяет возможности и права сотрудника, необходимые ему сервисы и документы. В виде групп представляются также горизонтальные связи (например, всех системных администраторов удобно объединить в группу, наделенную исключительными правами доступа) и всевозможные временные образования – например, коллектив, работающий над неким проектом и составленный из сотрудников разных подразделений, или бюджетный комитет, который собирается по пятницам и решает вопросы финансирования. Для временных групп в каталоге указывается "срок жизни"; права доступа к календарю, к документам, средствам проектного управления и т.п. им назначаются точно так же, как и группам, существующим на постоянной основе, но действуют только в течение ограниченного периода времени. Схема, основанная на использовании организационной структуры предприятия, оптимальна с точки зрения администрирования. Действительно, при всевозможных кадровых перестановках изменение информации об отделе и должности сотрудника автоматически влечет соответствующее изменение набора необходимых ему сервисов и документов. Иной подход потребовал бы от системного администратора описания в явном виде нового набора прав.

Безопасность
Чтобы связать зафиксированные в каталоге права пользователей непосредственно с сервисами, используются списки доступа (так называемые ACL – Access Control Lists)– разновидности таких списков присутствуют во всех операционных системах, поддерживающих разграничение доступа к каким-либо ресурсам. Однако если для обычных ресурсов еще можно пытаться использовать некий упрощенный единый набор прав, то в случае специализированных сервисов, доступ к которым предоставляет портал, это абсолютно нереально, и здесь применяется подход, основанный на индивидуальном описании наборов прав. Каждому сервису сопоставляется набор реализованных в нем действий – так называемых акций (actions). Скажем, для документного хранилища это чтение, запись, удаление, подписка на извещения по электронной почте об изменениях и т.д., акции для управления проектом включают заведение нового проекта, редактирование сроков выполнения задач, назначение исполнителя и другие подобные операции. Между акциями и группами пользователей устанавливается соответствие, которое удобно представлять в виде таблицы: по горизонтали записываются группы, по вертикали – акции, а в клетках указываются права. (Формально допускается назначение прав не только группам, но и непосредственно пользователям, однако это не рекомендуется по соображениям простоты администрирования; если необходимо наделить кого-то уникальным набором прав, лучше создать группу из одного человека.) У права есть три состояния: разрешено, запрещено, не определено. Если право не определено, это означает, что оно наследуется. Правила наследования свои для каждого сервиса. В документном хранилище, например, вместе с доступом к той или иной папке по умолчанию естественно предоставить доступ и ко всем папкам, вложенным в нее. В проектном управлении подзадача обычно не наследует прав главной задачи, потому что чем глубже задача, тем ниже в служебной иерархии находится исполнитель, которому она поручается. Поскольку в портале необходимо периодически анализировать различные события, связанные с группами и правами доступа, в системе безопасности предусмотрено так называемое журналирование, т.е. фиксация действий пользователей. Чем больше компания, тем сильнее востребован соответствующий сервис.

Отступление 1: о централизации и распределенности
Теоретически портал для распределенной компании можно сделать как централизованным, так и распределенным. Однако на практике, по опыту "Город-Инфо", централизованное решение почти всегда выгоднее: даже при недостаточной пропускной способности каналов обычно дешевле расширить канал, чем заниматься тиражированием портала, – настолько значительные средства экономятся за счет простоты. Когда вся информация существует в единственном экземпляре, нет необходимости в сегментации баз данных, достаточно запутанном распределенном администрировании, синхронизации. Кроме того, портал – живое образование, он постоянно развивается, и понятно, что добавлять новые сервисы в одной точке легче и удобнее, чем в нескольких. Линии связи сейчас дешевеют (заметим, кстати, что приложения, работающие в интранет-архитектуре, используют каналы достаточно экономно, особенно по сравнению с клиент-серверными), а администрирование дорожает, так что вывод о выгодности централизации напрашивается сам собой. И он подтверждается объективными расчетами: консультанты Price Waterhouse, исследовавшие вопрос о том, какое решение – централизованное или распределенное – предпочесть для ТНК, сделали однозначный выбор в пользу централизации. Но при том, что сам портал тяготеет к централизованному решению, его администрирование, как считают в "Город-Инфо", должно быть распределенным, хотя бы по той простой причине, что увольнение одних и прием на работу сотрудников происходит на местах. Отсюда возникает дополнительное требование к системе безопасности – она должна обеспечивать безопасное делегирование полномочий на администрирование ограниченных частей каталога пользователям на местах. Без этого портал работать не сможет.

Персонализация
Как одну из основных функций портала, наряду с обеспечением безопасного доступа к сервисам, специалисты "Город-Инфо" рассматривают персонализацию, т.е. предоставление пользователям индивидуальной рабочей среды, отвечающей их потребностям и личным предпочтениям. Для каждого пользователя в портале поддерживается так называемый профиль, который создается при его первом входе в систему. Фактически профиль представляет собой хранилище параметров работы с порталом – как общих (касающихся главным образом оформления), так и относящихся к отдельным сервисам, в которых предусмотрена возможность запоминать в профиле пользователя сделанные им настройки. Депозитарий профилей един для всей системы и всех сервисов. Между сеансами работы профиль хранится в базе данных, а в начале очередной сессии восстанавливается. Так что пользователь, придя в офис и включив компьютер, автоматически оказывается в той же самой среде, что и перед уходом, вплоть до того, что видит список последних документов и папок, с которыми работал.

Фундамент для портала
Естественно, функционирование инфраструктуры обеспечивает сервер приложений. "Город-Инфо" имеет опыт работы со многими серверами – Oracle, iPlanet (Sun ONE), Hewlett-Packard Application Server, JBoss – собственно, подходит любой, поддерживающий стандарт J2EE. У каждого варианта есть свои плюсы и свои минусы с точки зрения масштабируемости решения, кластеризации и хранения, поэтому выбирать сервер приложений нужно очень тщательно. Следующий компонент – базы данных. С точки зрения "Город-Инфо", конкретная СУБД не очень важна, так что ее выбор определяется характером бизнес-задач и пожеланиями заказчика. Непосредственный опыт работы у специалистов компании есть с MS SQL, Oracle и открытой СУБД Postgresql, использование которой может стать выходом при жестких бюджетных ограничениях. Oracle явно лидирует в проектах для крупных компаний, в то время как в решениях среднего масштаба значительна доля MS SQL.

Отступление 2: о порталах корпоративных и публичных
Поскольку компания "Город-Инфо" разрабатывает и корпоративные порталы, и публичные сайты, ее специалисты имеют полную возможность сравнить одно с другим. По их мнению, между этими двумя классами задач очень мало общего, и корпоративный портал очень сильно отличается от публичного, такого, как Yahoo! или "Яндекс". У них разные функции и, соответственно, они имеют отличия в архитектуре. Например, работу над корпоративным порталом, как говорилось выше, естественно начать с определения ролей пользователей – именно роли послужат основой для всего дальнейшего. В то же время в публичных порталах они никого не интересуют. Возможности персонализации там обычно невелики, особенно по сравнению со "сквозной" персонализацией корпоративных порталов, и сводятся к настройке одной-единственной страницы. Это естественное ограничение технологии: при той посещаемости, какая характерна для публичных порталов, сервер не смог бы генерировать множество динамических персональных страниц для каждого пользователя. Та же высокая посещаемость заставляет разработчиков публичных порталов усиленно стремиться к оптимизации работы Web-страниц – для корпоративного портала, число пользователей которого относительно невелико, оптимизация страниц не имеет большого значения. Поскольку различия носят глубокий и принципиальный характер, в "Город-Инфо" с недоверием относятся к готовым решениям для корпоративных порталов, созданным на базе решений для порталов публичных, и наоборот. Поговорим теперь о запрошенных в задаче бизнес-функциях.

Документы в портале
Начнем с управления знаниями, контентом, документами и структурирования информации. Задачу управления так называемыми неявными знаниями, т.е. информацией, хранящейся в головах людей, специалисты "Город-Инфо", скорее всего, стали бы решать с помощью Lotus Discovery Server (LDS) – отличного продукта, который хорошо вписывается в предлагаемую архитектуру. Однако на сегодня заказчики, как правило, озабочены существенно более примитивной проблемой – упорядочением информационного обмена. Для ее решения в первую очередь необходимо создать некое хранилище, в котором документы были бы правильно организованы, "рассортированы", расклассифицированы и разложены по систематизированным папкам. Такое хранилище может содержать информацию разных типов. С внешней точки зрения она представлена в виде файлов, но технически хранится в базе данных – это упрощает администрирование, резервное копирование и другие операции. Рассмотрим подробнее, какие функции должны быть реализованы для хранилища. Чтобы пользователи могли извлекать из хранилища нужные им документы, необходимы полнотекстовая индексация и архив с учетом прав доступа (т.е. если документ для пользователя закрыт, ссылка на него не будет выдана, так что пользователь просто не узнает о его существовании). Крайне желательно, чтобы архив поддерживал максимальное число различных форматов файлов: скажем, не только Word и Excel, но и PDF, текстовый формат, HTML – вообще чем больше, тем лучше. Так, Oracle предлагает технологию, называемую intermedia text, которая обеспечивает полнотекстовый индекс для более чем 50 форматов документов, и это не представляется излишеством. Поддержка многих форматов особенно полезна на начальном этапе работы с хранилищем, поскольку позволит сразу собрать имеющиеся разрозненные документы. Ею не следует пренебрегать даже в том случае, если на предприятии уже действует некий корпоративный стандарт, ограничивающий набор допустимых форматов: наверняка он введен не слишком давно, и некоторые "нестандартные" документы вполне могут пока сохранять актуальность. Если стандарта нет, его, бесспорно, необходимо ввести, но удобнее рассматривать эту задачу независимо от построения документного хранилища. Поскольку документы, помещаемые в корпоративное хранилище, имеют некий официальный статус, нужно обеспечить регламент их публикации. Иначе говоря, приказы, правила, распоряжения руководства должны согласовываться и утверждаться теми же инстанциями, что и при их издании на бумаге. Добавив к этому систему оповещения заинтересованных лиц о появлении нового документа, мы получим точный электронный эквивалент схемы "зайди к директору и распишись, что ознакомлен с приказом" (сотрудников, от которых необходимо подтверждение, можно включить в список визирования). Каждый электронный документ, так же, как его печатный аналог, должен быть снабжен "карточкой" с набором атрибутов, заполняемой при его публикации. В решении "Город-Инфо" атрибутика документа расширяемая. Удобно будет разработать несколько шаблонов атрибутики для разных типов документов. Естественно, нужна работа с версиями документов, а в системе безопасности следует предусмотреть права на администрирование документов и управление ими, причем с возможностью делегирования. Желательно реализовать доступ к хранилищу не только через Web, но и через Web-папки. Это позволит работать с хранилищем как с файловой системой.

Об аналитике, бухгалтерии и прочем
Что касается запрошенного в задаче управления данными с их очисткой, планированием, администрированием и т.д., то это функции систем типа data warehousing, которые не имеют непосредственного отношения к портальной технологии. Одно решение такого рода у "Город-Инфо" все-таки есть – это система оперативного мониторинга процессов таможенного оформления и контроля для ГТК. Необходимость реализовать аналитическую систему в рамках портальной технологии была связана с тем, что с ней должны были работать многочисленные пользователи в самых разных точках страны. Обычно же пользователей у систем OLAP, аналитики и т.п. немного, и это достаточно узкая категория специалистов. Другое дело что и исходные данные для их работы, и результаты в виде уже очищенных, агрегированных данных могут быть опубликованы в портале. Однако выносить в портал саму работу с данными сложно и, как правило, не нужно; заниматься ею в обычном интерфейсе ПК или рабочей станции значительно удобнее. Сказанное относится и к запросу о безопасной интеграции с финансово-учетной системой, установленной на предприятиях холдинга. Прежде всего нужно определить потребителей соответствующей информации и степень целесообразности ее предоставления через портал. По-видимому, и здесь самым разумным окажется помещение в портал только отчетности (с нужным образом определенными правами доступа): Web-клиент бухгалтерской программы был бы чудовищно неудобным в работе. На рынке существует несколько предложений порталов с функцией data warehousing. Специалисты "Город-Инфо" советуют с осторожностью подходить к таким продуктам – скорее всего, это не очень качественная система data warehousing и не очень качественный портал.

Внедрение: руководитель должен быть лидером
Схема внедрения портала достаточно стандартна: система развертывается на выбранном для этой цели оборудовании заказчика и к ней подключается ограниченное количество пользователей, которые начинают ее опытную эксплуатацию. Затем разработчики собирают замечания и предложения этих пользователей, вносят в ПО необходимые коррективы и после этого запускают портал в промышленную эксплуатацию. Какие именно пользователи выступят в роли "подопытных кроликов", зависит от корпоративной культуры заказчика. Часто готовность принять участие в эксперименте выражают сотрудники руководства: они в первую очередь заинтересованы в портале, который нужен им и для подчиненных, и для себя. Как одну из самых удачных демонстраций возможностей портала в "Город-Инфо" вспоминают эпизод, когда разработчики показали одному из высших менеджеров некой компании полный список тех комитетов, в которых он участвует – является куратором, ответственным секретарем и т.д.; сам он не мог назвать даже их количество. Это, конечно, было убедительно, а после того, как менеджеру вывели список запланированных заседаний по всем этим комитетам, у него исчезли и последние сомнения в полезности портала.

Сколько это может стоить
На вопрос о стоимости портала ответить несложно: она складывается из двух частей – стоимости лицензии и стоимости комплекса работ по интеграции портала в существующую информационную систему предприятия, его установке, доработке, созданию специфических модулей, нужных заказчику. Для крупной компании стоимость портального проекта в чистом виде составляет $120–250 тыс. Средней компании портал может обойтись в меньшую сумму – порядка $40–70 тыс. Что же касается мелких компаний, то им решения данного класса, по-видимому, вообще не нужны. Сложнее сказать, как быстро окупится портал. Он не приносит "живых" денег, но экономит средства за счет лучшей организации инфраструктуры, более эффективного использования времени сотрудников, повышения их осведомленности и производительности труда. Определенные методики, позволяющие дать всем этим факторам числовую оценку, существуют, но специалистам "Город-Инфо" неизвестны достаточно удачные попытки их применения ни в России, ни за рубежом. Во многих случаях речь, видимо, должна идти не о количественной, а о качественной оценке: портал ценен как механизм, обеспечивающий устойчивое поступательное развитие предприятия, поддерживающий мощную корпоративную культуру. Такого мнения придерживаются многие руководители. Вице-президент ТНК Александр Блох в ответ на вопрос об экономической эффективности портала отметил, что вопрос для него заключался не в экономической эффективности, а в возможности дальше развивать компанию как единое интегрированное целое: "Портал – это просто цена "билета" для тех, кто собирается заниматься современным бизнесом". r

 
сетевой форум
архив
подписка на журнал
о сетевом

подписка на новости

подписка на журнал

архив номеров

архив новостей