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