Мы определились как оценивать системы: получаем оценки функциональной части системы, оценки ее технологического совершенства, после этого продукт и его оценка попадает в следующий модуль системы «Федерация» — каталог групповых решений. Структуру и принцип построения этого, последнего, компонента «Федерации» нам осталось рассмотреть.

Для общего понимания каталог «Федерации» — это магазин технологических продуктов Gруппы, в котором есть свои специализированные отделы (АБС, CRM, ДБО), на витринах которого представлены ИТ‑решения в уже проведенной оценкой, которую нужно применить для конкретную организацию.

Формирование критериальной модели, как было показано выше, организовано «с руки» заказчика: каждый критерий — это некоторая задача или требование с его стороны и нам требуется оценить, как данная задача или требование реализованы в конкретных системах. В концепции системы «Федерация» заложена двухфазная оценка системы.

- Централизованная оценка: мы оцениваем решение, что в нее заложено в принципе, какие задачи «всплывали» в голове проектировщика этой системы и как они решены

-  Локализация: централизованную оценку системы «вообще» нужно применить к локальной организации – не все «опции» всем нужны

В этой части мы рассмотрим, как организуется общая централизованная оценка несколькими экспертами и как она локализуется для конкретной организации по «развесовке» критериев.

Структура оценки определена, но для проведения самой оценки необходима информация для анализа. По опыту, сбор таких данных является весьма трудоемким процессом. Данные в различных источниках, нужно пообщаться с разными людьми и т.д. Часто сбор данных превращается в настоящее расследование. Дело увлекательное, но может стать очень долгим.

Ключевой момент в решении этой задачи собирать данные универсальным способом, чтобы эксперты, участвующие в оценки «на вход» получали данные в более или менее унифицированном виде, с минимальными «дорасследованиями». Логично подготовить «технологическую анкету» по каждой системе, чтобы поставщик системы знал, что и в каком виде от него требуется.

Блоки критериев «Общие сведения», «Корпоративная архитектура», «Прикладная архитектура», «Архитектура данных» и т.д., оценивают систему «в целом» – по сути это набор функциональных и нефункциональных требований к системе, но без специфики функционала системы. Нужно оценивать и функционал системы, по ее прямому назначению. Для этого в критериальной модели для каждого типа систем предусмотрена специализированная часть.

Сравнение АБС с CRM выглядит удивительно, сравнивать нужно системы одного класса, одной функциональной области. Суть этой части критериальной модели – типовые функциональные и нефункциональные требования к системам. Функциональные области у нас есть в типовой архитектуру (см. часть 4 Размечаем площадку), вот по этим областям и будем оценивать системы.

Оценка систем по критериям - понятная конструкция, но как оценивать системы совершенно разного прикладного назначения, есть системы типа CRM, АБС, процессинги, интеграционные решения и т.д.? Тут следующая мысль: каждая информационная система, все же система, т.е. у них всех имеется что-то общее, что можно сравнивать.

Наша критериальная модель построена именно исходя из этого соображения. Часть критериев рассматривает техническое совершенство системы, а другая часть оценивает насколько решение соответствует требованиям, конкретной функциональной области.

Первый архитектурный инструмент системы принятия решений – функциональную архитектуру – мы рассмотрели, следующий по логике рассмотрения критериальная модель оценки. Перед тем как рассматривать ее нужно определиться с принципами ее построения.

В этой части мы разберем постановку задачи на проектирование критериальной модели оценки. Какие «пользователи» будут у модели, какие у них требования к ней (точнее интересы) какие конфликты этих интересов могут случится и как их «разрулить»?

Мы планируем оперировать системами в ИТ-ландшафтах , тут возникает желание расчертить площадку, по которой будем «двигать» наши системы – фигуры или другими словами задать систему координат. Причем важно заметить, что система координат для организаций одного типа ожидаемо должны быть подобны.

Очевидно нам нужно выделить слабосвязанные области, унифицированные по возможности для разных типов организаций – эти области и станут те ми клеточками, по которым мы и будет расставлять фигуры – gрупповые информационные системы.

Важная мысль, которая была поднята в «Кодексе архитектора» - для того чтобы добиться успеха нужно, чтобы все отработали как надо, один не доработает – и успех уже не так гарантирован. Это очевидная штука, но как с более тонкими моментами? В связке «архитектор» - «владелец продукта» не то чтобы не «косячить», как тянуть в одну сторону?

Архитектор работает с владельцем через требования, т.е. от иногда надевает «шапку владельца продукта», чтобы понимать, что делает и как это будет использоваться в будущем. Я хочу предложить владельцу продукта «шапку» архитектора.

В предыдущей части мы сформулировали постановку задачи тиражирования решений и систем в федеративной структуре. Мы рассмотрели ключевой конфликт интересов между централизацией и локализацией – который является, на мой взгляд, имманентным свойством всех таких структур. В этих условиях нужно обеспечить балансировку этих интересов, с целью повышения эффективности Gруппы в целом с помощью системы принятия решений, обеспечивающий эту самую балансировку. Система принятия решений видится подобной системе «дестрастных» дифференциальных уравнений с начальными и граничными условиями.

В этой части мы рассмотрим элементы этой системы принятия решений, которые детализируем в следующих частях и в конце цикла, соберем всю систему из готовых компонентов.

Есть представление о том, что в родной стране вопрос корпоративной архитектуры в отдельно взятой организации более или менее решен. Как правило, имеется своя методология, основанная на каком-то каркасе (типа Togaf или что-то в этом роде), репозиторий и операционный контур, для принятия соответствующих решений в части корпоративной ИТ-архитектуры и прочее. Есть вопросы, но они уже относиться к частностям и решаются, что называется в рабочем порядке. 

Мне бы хотелось поднять вопрос на уровень выше. Корпоративная архитектура групп компаний, холдингов, отраслей экономики и т.д. Одним словом, в распределенных структурах с центральным руководящим органом и участниками объединения(федерация), для которых нужно согласованное развитие корпоративной архитектуры.

Проще говоря корпоративная ИТ-архитектура в федеративных структурах. Во как! Страшно было выговорить, но сумел .

Да, еще хотел предупредить, дальше будет «много букв» и дочитать нужно до конца, если вы заинтересованы в результате. Итак, приглашаю в клуб профессиональных читателей.

Если организация имеет определенное имя (бренд) в бизнесе которым она разрабатывает, то логично что этот бренд развивается специализированным подразделением – PR/JR и т.д. Так делают все приличные организации. Бизнес современных организации имеет существенную технологическую составляющую – посмотрите на банки, маркетплейсы, страховые и другие компании и возникает вопроса – а нет ли смысла вести на рынок бренд организации не только в части его «прямого» бизнеса, но сделать его технологическую составляющую  часть общего бренда.

В данном материале я поделюсь соображениями о расширения основного бренда организации технологической составляющей. Технологический маркетинг.

Моей жене и детям посвящается.

Действительно, есть, одна проблема: можно ли реализовать омниканальную архитектуру в неомникальной организации? Как у Петра Первого, можно пробовать построить Санкт-Петербург и так, но может оказаться, что и бороды надо брить. Причем с этого и надо начинать. То-то и оно. Для новой архитектуры нужно менять и организацию. Как это сделать — в финальном эпизоде. 

Итак, мы узнали об омникальности достаточно. Витрины, продукты, СУБО а в жизни то что? Концепции, принципы – да где посмотреть Конечно, здесь – мы занимаемся этим с 2020 года, и кое-что получилось. 

Хочется поговорить с умным человеком (это я про тебя читатель). Все то, что мы рассказывали раннее — это поколение 4++. Теперь нужно сделать следующий шаг в будущее. На «пятерку». Было страшно. Но глаза боятся, а руки делают! Главное не оглядываться, а то упадешь. Делаем омниканальное банковское ядро.

Теперь мы знаем, что за «коктейль» у нас получается и важно, что логика идет снизу-вверх, что позволяет нарезать ее так, как нужно потребителю. Видно: витрины — канальные приложения, продуктовые системы — СУБО, общие элементы ОПС/ОС/СС. Красиво? Вроде да, но как-то уж больно просто. Неужели в производстве все также гладко?

В предыдущем эпизоде мы собрали общую конструкцию, соответствующую формуле омниканальности. Определены слои и ингредиенты для каждого слоя, даже в виде одной фразы приведен общий рецепт предлагаемого напитка. Теперь надо пробовать этот коктейль, но как?

Собираем конструкцию омниархитектуры по слоям. В этом эпизоде мы узнаем: из каких слоев состоит омниканальная платформа, какие элементы находятся на каком слое и для чего они нужны. В конце сформулируем, что такое омниканальная архитектура одной фразой! Фраза, конечно, не как у Льва Николаевича (Толстого), но нужно дотянуть до конца. Мы не редкие птицы, но Николай Васильевич (который Гоголь) должен подсобить.

С багажом из предыдущих серий мы отравляемся в следующий эпизод, в котором мы определим имманентные (простите вырвалось) проблемы ИТ-архитектуры 4-го поколения, на примере ВТБ 2019 года выпуска. А также узнаем, как решаются эти проблемы в Омниканальной архитектуре. В рамках этого мы сформулируем формулу омниканальности.

В предыдущем эпизоде мы посмотрели, в какой точке был ИТ-ландшафт ВТБ, и что привело его в эту конкретную точку. ИТ-архитектура была в принципе вполне нормальна, отвечала задачам бизнеса на тот момент и в принципе «каши не просила». В 2019 была точка принятия решения, что делать дальше? Какая «погода», какие технологические тренды дуют, пойдем или полетим, сидим в гавани или идем в открытое море. 

В первом эпизоде первого в мире архитектурного сериала мы определились с буквами, словами и терминами. Теперь мы рассмотрим траекторию развития ИТ вообще, что двигало это развитие, какие задачи решались и какими средствам. Какая траектория была у ИТ-ландшафта ВТБ и в какой точке мы были в 2019 году.