Система «Федерация». Часть 1/10 Традиционная: Общая постановка задачи
Начнем с постановки задачи. Обычный подход — контекст, задача, вводные и решение задачи. Рассмотрим проблему тиражирования прикладных решений в федеративной структуре именно в такой системе координат.
Постановка задачи:
Контекст: Имеем некую распределённую структуру: финансовая группа, банковская (что лично мне близко) отрасль в целом или другой сектор экономики родной страны. В принципе не важно, хоть отрасль Евразии, главное распределенная федеративная структура : есть управляющий центр и принимающие его управление организации.
Задача: Обеспечить согласованное управление прикладной архитектурой в распределенной структуре в части использования прикладных информационных систем (технологических прикладных продуктов ТПП). В дальнейшем будем называть эту структуру кратко Gруппа (c большой буквы «Г»). Условно — корпоративный технологический магазин, куда участники Gруппы могут зайти и «отоварится».
Вводные:
Члены Gруппы самостоятельные ЮЛ по бизнесу, т.е. бизнес решения принимаются локально, для центра главное экономическая эффективность
Центр определяет базовые технологические стандарты, соответствующие стратегии технологического развития Gруппы
Т.е. вырисовывается такая централизованная конструкция. В таких конструкциях, как показывает диалектика т.Гегеля, заложены два вступающих в противоречащие явления: централизация и локализация. Это не уникальная ситуации именно для управления архитектурой в группе компаний, подобные противоречия, или конфликт интересов сопровождает человечество всю его историю. Конфликт Ивана Безземельного и английских баронов (помните, Хартия вольностей), Ивана Васильевича (любого) и боярства, феодальная раздробленность Руси и масса других примеров. Причем, как можно видеть в истории нет правых и виноватых, когда-то уместна была централизация, а когда-то она выходила боком — нужен баланс.
Вернемся к нашей задаче: имеем прекрасный технологический продукт и внедрив его во всех дочках, получим взаимное усиление (синергию) ГО и дочки. Наверное?
Это идеальная ситуация, к которой мы все стремимся, но реальность играет большими красками. А если централизованный продукт не так хорош и/или, по сути закрывает потребности Головного офиса (ГО) на площадке дочки, а не потребности дочки? Налицо конфликт интересов.
Дочки хотят максимально удовлетворить свои потребности с минимальными затратами
ГО (центр) хочет максимально унифицировать используемые в ГО решения для всех участников группы
Имеем, две крайности :
ГО склонно «продвигать» унифицированные решения, даже не смотря на их недостатки в каждой конкретной дочке, с которыми будет «бороться» локальная команда. Т.е. унификация за счет дочек.
Дочка (участники) хочет иметь возможность самостоятельно развивать свою ИТ-архитектуру и не платить «налог» на унификацию.
Разумеется, это предельные ситуации, но реальность, или «мутная» зона, где-то по середине. Такая ситуация может привести к тому, что в этой «мутной» зоне будут постоянные конфликты, эмоции, недетерминированность принятия решений в каждом случае. Это неизбежно приведет к тому, что сроки, качество и трудозатраты людей, физические и нравственные будут оставлять желать много лучшего.
Из всего вышесказанного вытекает следующая мысль: нужна некоторая система принятия решений, которая позволить находить оптимальный баланс между интересами «центра» и «дочек». Как мы это любиv — этакая система «бесстрастных» дифференциальных уравнений в частных производных с граничными и начальными условиями. Причем важно, система уравнений беспристрастна — какие начальные и граничные условия дадите на вход, такой результат и будет на выход.
Основная идея лежит в
четком определении интересов всех участников и объединение этих интересов в общей критериальной модели (система уравнений) для каждого рассматриваемого решения
по каждому критерию (частной производной) будет проведен анализ экспертами в данной области
решение будет приниматься на основе анализа решений в общей системе координат, что положительно скажется на управляемости процесса, сроках, качестве и «душевных» затрате участников
Разумеется, такая система не может висеть в воздухе, для ее поддержки нужен управленческий контур.
Итак, мы замахиваемся на создание системы детерминированного принятия архитектурных решений, поддерживаемая управленскими процессами организации.
Посмотрим, как это может выглядеть.
