Сформулируем цель для нашей системы принятия архитектурных решений «Федерация» более четко следующим образом:

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

Определим базовые блоки «Федерации» для типовой Gруппы компаний (финансовой, промышленной – нет разницы), так чтобы можно было бы легко адаптировать приведенную схему к конкретной организации.

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

**Рис. 1. Типовой управленческий контур**

Архитектурные инструменты: это необходимые средства управления корпоративной архитектурой.

Функциональная архитектура(ФА) – таксономия функциональных областей, декомпозирующей бизнес конкретной организации, на слабосвязанные области деятельности: фронты продаж и обслуживания, Управление сотрудниками, бух и налоговый учёт. Аналоги Business Capabilities в TOGAF, не зачем изобретать велосипед.
Критериальная модель(КМ) для оценки различных информационных систем. Мы рассмотрим КМ более подробнее далее, сейчас обзор общей архитектуры системы принятия решений (СПАР).
Каталог «Групповых прикладных решений»: каталог – это место, куда будет попадать системы, прошедшие определенную оценку по критериальной модели и рекомендованные для тиража в определенные функциональные области (см. выше).

Источники продуктов: по сути партнеры, текущие и потенциальные поставщики Gруппы. Обычно их можно распределить на следующие домены:

Партнеры – поставщики, уже имеющие отношения с Gруппой. Причем это могут быть как «ситуативные» партнеры, так и стратегические.
Рынок – это рынок, что тут скажешь. Причём, важно заметить, что в данном случае рынок может быть международным, если Gруппа имеет несколько стран присутствия.

Потребители продуктов: компании Gруппы, где мы и должны наладить процесс выбора решений в их ИТ-ландшафт. Для рассмотрения более сложного для управляемости организационного устройства Gруппы, примем, что участники Gруппы, самостоятельные ЮЛ, со своей, локальной закупочной процедурой, но архитектурные стандарты, унифицированы на уровне методологии моделирования корпоративной архитектуры. Исходя из этого предположим, стандарт нашей Группы определяет следующие понятия:

Целевая прикладная архитектура (ЦПА)(: связка функциональных областей функциональной архитектуры (ФА) и конкретных систем, автоматизирующих эту функциональную область (см. Далее). Например, область CRM реализуется Siebel CRM, запрещенный в ЗОО КИ РФ, а АБС – ЦФТ, ДБО BSS и т.д. Тут пока ничего нового, принципы TOGAF.
Каталог, или реестр информационных систем(РИС): список информационных систем, используемых в ИТ-ландшафте конкретной организации.

Включение системы в РИС конкретной организации – это тиражирование системы в организацию, а в какую функциональную область - это целевая прикладная архитектуру(ЦПА) конкретной дочки.

Все выше описанное «собирается» в единую схему некоторыми архитектурными процессами:

Первый процесс — это управление основным инструментом оценки — критериальной моделью. Инструмент требует регулярной «правки», «заточки» кромки и для этого нужна операционная модель. Конечно рассмотрим. Позже.
Второй процесс — это сама оценка решений, для включения в каталог групповых продуктов. Тоже, обсудим.
Третий процесс — это актуализация ЦПА конкретной организации, с включением решения из каталога «Групповых прикладных решений».

Требования уточнены, начнем проектировать архитектуру «Федерации».

Что имеем на входе :

множество продуктов, которые мы хотим тиражировать в Gруппу с одной стороны
с другой стороны - потребителей этих продуктов - участники Gруппы

Явно видны два контекста – контекст поставщика и потребителя. Они объективно не связаны – действительно, создатель продукта при его проектировании имел в голове свое понимание «использования» своего детища.

Например,

«Мой CRM продукт будет использоваться в «ламповой» организации – в теплой части нашей Родины исключительно для задач операционного CRM» – мечтательно и с легким оттенком наивности подумал Поставщик.
«Операционный CRM – хорошо, мне еще нужен MDM – почему нет» - с блеском архитектурного азарта замечает про себя Потребитель №1
«а чего еще и досье клиента в нем реализовать» - простодушно, подхватывает Потребитель №2

**Рис. 5. Продукты, потребители – «многие-ко-многим»**

Т.е. нужна оценка одного решения в контекстах различных потребителей. Что делаем, будем решать задачу «в лоб» и оценивать продукт для каждого потребителя отдельно. Т.е. каждый потребитель оценивает продукт под себя исключительно. Здесь видятся два недостатка:

Трудоемкость каждой конкретной оценки по используемым ресурсам – команда экспертов нужна в полном составе и каждый раз. Они должны будут погружаться в контекст потребителя каждый раз и проводить полный анализ.
«Мутная зона» - здесь у нас оценки идут «мимо» ГО Gруппы. Т.е. 3-5-10 «междусобойчика». Кручу-верчу, себе выбрать хочу. Есть существенный риск потери управляемости.
Масштабируемость – если в полку участников Gруппы прибыло – опять собирать всю команду оценки и засучив рукава приниматься за дело

Как-то неопрятно.

Здесь разумно предложить для решения этих и не только этих проблем двухфазный процесс:

Фаза 1 Централизованная: Сперва проработка общей централизованной оценки, проведенной, что называется, на полный штык. Как в свете федеральных стандартов выглядеть решение, другими словами – продукт вообще?
Фаза 2 Локальная: Следующий шаг – адаптация общей оценки к контексту организации. Например, эта особенность оцениваемого решения для одних участников Gруппы важна, или для кого-то не так. «Прикручиваемость» к системе функционала досье клиента одному потребителю хорошо, а другому все равно, а третьему – вообще «кость в горле», у него свое досье есть.

**Рис. 6. Централизация – двухФазная оценка**

Мы добавляем еще один контекст в нашу задачу – федеративный или gрупповой контекст. Такая «двухфазная» централизованная схема балансирует управляемость (Централизация) тиражирования технологий и гибкость для учета контекста участника Gруппы (локализация).

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

**Рис.5 Профилирование оценки весами конкретного потребителя**

Детали критериальной модели мы посмотрим позже, сейчас важно понять, что на этой фазе мы получаем оценку решения в системе ИТ-координат Gруппы.

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

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

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

Таким образом, ключевым архитектурным решением в проектировании СПАР «Федерация» является двухфазная диалектичная оценка.

Теперь, исходя из выше сказанного у нас получается следующая конструкция:

Продукты представлены на рынке стран пребывания Gруппы
Поставщиками этих продуктов могут быть партнеры Gруппы – как стратегические, так и ситуативные (здесь и сейчас этот продукт этого поставщика будет весьма хорошо)
Фаза 1 : Централизованная :
- поставщик продукта, которые имеет намерение предложить свой продукт в Gруппу, предоставляет информацию о своем желании и данные о продукте в карточке продукта «Федерации» (посмотрим позже). Важно,что карточка - это не столько анкета, которую нужно заполнить, сколько список данных, которые необходимы для оценки системы.
- продукт (по данным представленным в карточке) оценивается по определённому набору критериев – критериальная модель, в рамках некоторой рабочей группы или Архитектурного комитета
- оценка утверждается на технологическом коллегиальном органе Gруппы и соответствующая оценка помещается в каталог Групповых решений
  - важно заметить, что в данном процессе оценивается техническое совершенство системы. «Экономика» - финансовые условия, цены и т.д. оценивается в другом контуре, мы ж лишь предполагаем, что эти вопросы решаются в рамках некоторой закупочной процедуры
- результатом этой фазы является централизованная оценка, которую мы смотрели выше

**Рис. 5. Общий двухФазный процесс управления**

Фаза 2 . Локальная : Как было дано в условиях задачи, каждая организация является самостоятельным ЮЛ и мы предполагаем, что в каждом участнике Gруппы своя собственная процедура закупки.
- Процедуры закупки в организациях по всей России, да и в мире, могут различаться, но в любой такой процедуре наверняка есть типовые шаги: «Формирование списка финалистов», сравнение финалистов
- На этапе «Формирования списка финалистов» в рамках закупочной процедуры необходимо просто «заглянуть» в каталог gрупповых решений
- Если в каталоге в есть система с соответствующим функционалом (CRM, MDM или ESB и т.д.), то нужно включить такое решение в список финалистов, для дальнейшего анализа
- После этого, на этапе анализа решений в рамках локальной процедуры, проводится локализация оценки –
  - функциональный анализ, на соответствие локальным функциональным требованиям (GAP-анализ)
  - применение локального профиля оценки (конкретные баллы для данной организации по критериям модели оценки). Т.е. если есть критерий «Импортозамещение», но для данной организации он не актуален (организаций вне РФ), то мы его обнулим или снизим до «ИТ-суверенитета»
- Экономические условия – вне рамок нашего технического материала, но этапе анализа финансов, очевидно своя модель оценки – ТСО и другие волшебные слова

Такой, представляется общая концепция, конструкция системы принятия архитектурных решений – СПАР «Федерация».

Далее мы рассмотрим ее составные части по отдельности и более детально.

Система «Федерация». Часть 2/8 Концепция