Система «Федерация». Часть 8/8 Каталог групповых решений

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

https://habr.com/ru/articles/899736/

#федеративная_итархитектура #федерация #корпоративная_архитектура

Система «Федерация». Часть 7/8 Двухфазная оценка систем

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

https://habr.com/ru/articles/897640/

#федеративная_итархитектура #федерация #корпоративная_архитектура

Система «Федерация». Часть 6.3/10 Критериальная модель – технологическая анкета

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

https://habr.com/ru/articles/893182/

#Федеративная_ИТархитектура #Федерация #Корпоративная_архитектура

Система «Федерация». Часть 6.2/10 Критериальная модель – функциональная часть

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

https://habr.com/ru/articles/893178/

#Федеративная_ИТархитектура #Федерация #корпоративная_архитектура

Система «Федерация». Часть 6.1/10 Критериальная модель – постоянная часть

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

https://habr.com/ru/articles/893168/

#Федеративная_ИТархитектура #Федерация #Корпоративная_архитектура

Система «Федерация». Часть 5/10 Критериальная модель – принципы построения

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

https://habr.com/ru/articles/894304/

#федеративная_итархитектура #федерация #корпоративная_архитектура

Система «Федерация». Часть 4/10 Разметим площадку

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

https://habr.com/ru/articles/893148/

#Федеративная_ИТархитектура #Федерация #корпоративная_архитектура

Система «Федерация». Часть 3/10 Наставление по проектированию продуктов. «Шапка» архитектора для владельца продукта

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

https://habr.com/ru/articles/893124/

#Федеративная_ИТархитектура #Федерация #корпоративная_архитектура

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

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

https://habr.com/ru/articles/893116/

#ФеФедеративная_ИТархитектура #федерация #корпоративная_архитектура

Система «Федерация». Часть 1/10 Традиционная: Общая постановка задачи

Есть представление о том, что в родной стране вопрос корпоративной архитектуры в отдельно взятой организации более или менее решен. Как правило, имеется своя методология, основанная на каком-то каркасе (типа Togaf или что-то в этом роде), репозиторий и операционный контур, для принятия соответствующих решений в части корпоративной ИТ-архитектуры и прочее. Есть вопросы, но они уже относиться к частностям и решаются, что называется в рабочем порядке. Мне бы хотелось поднять вопрос на уровень выше. Корпоративная архитектура групп компаний, холдингов, отраслей экономики и т.д. Одним словом, в распределенных структурах с центральным руководящим органом и участниками объединения(федерация), для которых нужно согласованное развитие корпоративной архитектуры. Проще говоря корпоративная ИТ-архитектура в федеративных структурах. Во как! Страшно было выговорить, но сумел. Разумеется я не замахиваюсь, на всю эту огромную тему (будем есть слона по частям), а предлагаю рассмотреть один из вариантов системы принятия архитектурных решений (СПАР) в части использования прикладных информационных систем в распределенной структуре, их подбор, оценка и тиражирование, на примере группы компаний. «Технологический магазин приложений» для распределенной федеративной структуры. Начнем, как обычно, с постановки задачи, далее рассмотрим необходимые архитектурные инструменты и управленческую «обвязку». Как обеспечить баланс между централизацией и локализаций, не скатится в «ИТ-колониализм» и не допустить «ИТ-сепаратизма». Приглашаю к дискуссии. Да, еще хотел предупредить , дальше будет «много букв» и дочитать нужно до конца, если вы заинтересованы в результате. Итак, приглашаю в клуб профессиональных читателей.

https://habr.com/ru/articles/893094/

#Федеративная_ИТархитектура #Федерация #корпоративная_архитектура