В продолжении серии «Через тернии к звездам»
Деление
Немного напомню ситуацию – у компании X есть много
«потребителей» информации, которая хранится в ECM-системе. Каждый потребитель довольно
специфичен как в плане используемой информации, так и в плане реализации. Кроме
того, у каждого потребителя различные требования к качеству доступа к информации – например, постоянный online-доступ без перерывов
(для сайта взаимодействия с клиентами).
Один из обсуждаемых вариантов выхода из сложившейся
ситуации – разделение единой ECM-системы
на отдельные, но связанные между собой системы. Поясню на рисунке:
Таким образом, предполагалось, в единой ECM-системе созрела необходимость
выделения специализированных систем,
которые обслуживали бы конкретных потребителей. Например, выделение системы для
работы с клиентами/партнерами, системы для поддержки технологических процессов
предприятия, и основной системы, где хранились бы все данные всех разделенных баз. Синхронизация между системами
могла происходить в пакетном режиме, т.е. снижалось зависимость
функционирования одной системы от другой.
Рассмотрим преимущества и недостатки такого подхода.
Сначала о достоинствах:
● Разделение
систем повышает их безопасность от внешних и внутренних атак. Например, если
взломают сайт взаимодействия с клиентами, то злоумышленники получат доступ
только к ЧАСТИ корпоративной информации и не смогут инициировать в основной
системе пагубные процессы.
● Относительная
независимость функционирования одной системы от функционирования другой.
Например, в случае краха или планового обслуживания базы для внутрифирменного
портала, сайт взаимодействия с клиентами будет работать в нормальном режиме.
● Возможность
разделения функциональных обязанностей по администрированию и поддержки баз.
Реальная ситуация – в компании X за ECM-систему отвечает отдел поддержки, а
сайты разрабатывает и поддерживает другой отдел – отдел веб-технологий.
Постоянно возникают ситуации, когда действия двух отделов влияют на
функционирования системы в целом. В случае разделения баз можно четко выделить
ответственность: например, за базу внутрифирменного портала полностью отвечает
отдел веб-технологий, которые не лезет в администрирование основной ECM-системы =).
● Также
интересный факт – не все системы нужно будет обновлять на новые версии. Если система
на старой версии работает хорошо и ее функционал полностью устраивает,
реального смысла обновлять на новую версию нет. Если обновляется версия
основной ECM-системы,
то достаточно изменить только механизмы синхронизации.
А теперь о недостатках. Основной недостаток – это резкое усложнение администрирования и
поддержки, в том числе и механизмов синхронизации между системами. Также не
стоит забывать о дополнительных лицензиях, которые придется докупать для
разделенных баз. Крайне желательно для каждой базы выделение отдельного
физического сервера, что также ведет к дополнительным расходам.
В этом варианте недостатки довольно серьезные. В следующих
записях я расскажу о других способах решения, которые были предложены к
реализации.
Продолжение.