[ «МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ И МНОГОКРИТЕРИАЛЬНАЯ ОПТИМИЗАЦИЯ АРХИТЕКТУРНОЙ ДОРОЖНОЙ КАРТЫ КРУПНОЙ КОМПАНИИ ...»
ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение высшего профессионального образования
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ
«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»
На правах рукописи
АГИЕВИЧ
Вадим Анатольевич
МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ
И МНОГОКРИТЕРИАЛЬНАЯ ОПТИМИЗАЦИЯ
АРХИТЕКТУРНОЙ ДОРОЖНОЙ КАРТЫ
КРУПНОЙ КОМПАНИИ
Специальность 05.13.18 Математическое моделирование, численные методы и комплексы программ Диссертация на соискание ученой степени кандидата технических наук
Научный руководитель доктор экономических наук, профессор М. И. Лугачев Москва Оглавление Введение
Глава 1. Существующие модели и методы планирования архитектурных преобразований
Введение
1.1. Архитектура предприятия как основа управления развитием информационных систем крупной компании
1.2. Архитектура предприятия с точки зрения системного анализа 1.3. Модели архитектуры предприятия
1.4. Методы планирования архитектурных преобразований.......... 1.5. Модели и методы формирования портфеля проектов.............. 1.6. Метод построения архитектурной дорожной карты TOGAF... 1.7. Выводы по главе 1
Глава 2. Модель реструктуризации архитектуры предприятия....... 2.1. Планирование технологических и организационных изменений предприятия на основе теории комплементарных взаимодействий 2.2. Принципы применения матрицы изменений
2.3. Формирование матрицы изменений на основе архитектурных блоков TOGAF
2.4. Построение математической модели взаимодействия архитектурных блоков
2.5. Построение модели реструктуризации архитектуры предприятия
2.6. Постановка задачи построения оптимальной архитектурной дорожной карты
Глава 3. Разработка методов построения оптимальной архитектурной дорожной карты
3.1. Сравнение поставленной экстремальной задачи со стандартными задачами комбинаторной оптимизации
3.2. Методы решения задач комбинаторной оптимизации............. 3.3. Алгоритм построения допустимых решений
3.4. Вычислительный эксперимент
3.5. Выбор метода решения задачи
3.6. Описание выбранного метода решения (генетического алгоритма NSGA-II)
3.7. Кодирование решений и выбор генетических операторов... Глава 4. Разработка и тестирование программного комплекса..... 4.1. Программная реализация системы построения и оптимизации архитектурной дорожной карты
4.2. Тестирование системы построения и оптимизации архитектурной дорожной карты
Заключение
Литература
ПРИЛОЖЕНИЯ
Приложение 1. Результаты вычислительного эксперимента......... Приложение 2. Листинг основной процедуры
Приложение 3. Листинг процедуры недоминируемой сортировки по алгоритму NSGA-II
Приложение 4. Основные экранные формы системы построения и оптимизации архитектурной дорожной карты
Приложение 5. Описание бизнес-кейса для тестирования системы построения и оптимизации архитектурной дорожной карты......... Приложение 6. Оптимальное решение и архитектурная дорожная карта
Приложение 7. Акты внедрения
Введение Актуальность темы исследования. В последние годы во всех секторах Российской экономики значительно расширилась область использования вычислительной техники, наблюдается устойчивый рост затрат на информационные технологии. Постоянно растет и сложность используемых информационных систем, возникают новые потребности в интеграционных решениях, повышается уровень требований к информации как внутри компаний, так и со стороны государства.
Создание сложных систем, производственных комплексов, систем управления этими комплексами часто требует использования знаний о количественных и качественных закономерностях, свойственных рассматриваемым системам. Главными проблемами при этом являются общесистемные вопросы, включающие определение структуры, организацию взаимосвязи между элементами, взаимодействие с внешней средой, управление функционированием как всей системы, так и ее отдельных элементов [38].
Одним из эффективных средств решения подобных проблем является использование моделей и методов архитектуры предприятия, давно применяемых крупными зарубежными компаниями, и в последние годы приобретающих все больше сторонников в России.
Архитектурный подход получил широкое признание как основа базирующейся на целостном многоаспектном представлении о эффективные возможности ее развития, естественной интеграции в среду функционирующей организации, интероперабельности с взаимосвязанными с нею системами и многие другие возможности.
Об актуальности и значимости архитектурного подхода свидетельствует, в частности, и тот факт, что ключевые элементы архитектурного подхода стали объектом внимания органов стандартизации международного и национального уровня, разрабатывающих официальные и индустриальные стандарты [23].
Как известно, современная бизнес-среда характеризуется высокой турбулентностью. Внешние изменения происходят быстро, но внутренние процессы принятия решений не успевают создать адекватную реакцию, поскольку не обладают адекватным источником и каналом обратной связи. Это является причиной того, что время, требующееся для перехода на новые бизнес-процессы и для реализации бизнес-стратегии, является новым "узким местом" [15]. Об этом же свидетельствует и возросший в последнее время интерес к концепциям «динамичности предприятия» (Enterprise Agility) и «предприятия реального времени» (Real-Time Enterprise, RTE). Чтобы выжить в таких условиях, предприятия вынуждены постоянно меняться, что, в свою очередь, требует разработки адекватных инструментов и методов эффективного изменения архитектуры предприятия в целом.
Несмотря на большое разнообразие методологий архитектуры предприятия, при их практическом применении проявляется ряд недостатков. Одним из наиболее существенных пробелов в этой области знаний является недостаточная проработка и слабая формализованность методов планирования перехода от текущего состояния архитектуры предприятия к целевому (разработки так называемой «архитектурной дорожной карты»). На сегодняшний день фактически отсутствуют формальные методы, позволяющие получить обоснованную архитектурную дорожную карту на базе моделей архитектуры предприятия. В крупных организациях данный процесс усложняется большим числом элементов архитектурных моделей.
Серьезным препятствием проведения дальнейших исследований является отсутствие математических моделей реструктуризации архитектуры предприятия и методов оптимизации процесса архитектурных преобразований, позволяющих рассматривать архитектуру предприятия в динамике и проигрывать различные сценарии ее развития при изменении внешних условий.
Таким образом, актуальной является задача разработки формальных моделей и методов планирования архитектурных преобразований крупных предприятий.
динамическая система.
Предмет исследования: модели процесса реструктуризации архитектуры предприятия.
Цель исследования: повышение качества преобразования архитектуры предприятия путем многокритериальной оптимизации архитектурных преобразований на базе графовой модели реструктуризации.
Задачи исследования:
1. Анализ моделей и методов планирования архитектурных преобразований с целью выявления классов вопросов, недостаточно проработанных в научной литературе и имеющих большую практическую значимость.
2. Разработка подхода к оценке характеристик архитектурной дорожной карты как последовательности преобразований архитектуры предприятия.
3. Построение математической модели реструктуризации архитектуры предприятия, включающей функции оценки архитектурной дорожной карты.
4. Разработка алгоритмов многокритериальной оптимизации архитектурной дорожной карты на основе модели реструктуризации.
5. Разработка программного комплекса для построения и оптимизации архитектурной дорожной карты.
Теоретико-методологическую основу исследования составляют системный анализ, архитектура предприятия, теория комплементарных взаимодействий, теория множеств, теория графов, математическая статистика, исследование операций, теория алгоритмов.
Научная новизна работы заключается в следующем:
1. Разработана математическая модель взаимодействия архитектурных блоков, учитывающая влияние факторов внешней и внутренней среды предприятия.
2. Разработана математическая модель реструктуризации архитектуры предприятия.
3. Разработан метод оценки качества архитектурной дорожной карты на основе модели реструктуризации архитектуры предприятия.
4. Разработан метод многокритериальной оптимизации архитектурной дорожной карты, учитывающий взаимодействие архитектурных блоков, факторов внешней и внутренней среды предприятия, а также приоритетность отдельных изменений.
предлагаемый метод многокритериальной оптимизации архитектурной дорожной карты.
Теоретическая значимость исследования. Предложена новая модель процесса реструктуризации архитектуры предприятия, а также средства оценивания этого процесса, показана их адекватность практическим задачам и возможность эффективной алгоритмической реализации. При этом впервые применены модели и методы теории комплементарных взаимодействий для разработки методов планирования архитектурных преобразований.
Практическая значимость исследования. Создан комплекс компьютерных программ для поддержки принятия решений при планировании преобразования архитектуры предприятия, а также для моделирования различных вариантов архитектурной дорожной карты при изменении факторов внешней и внутренней бизнес-среды. В отличие от существующих подходов впервые реализована возможность оптимизации архитектурной дорожной карты на основе формальных методов, учитывающих комплементарные взаимодействия архитектурных блоков.
Основные положения, выносимые на защиту:
1. Разработана математическая модель взаимодействия архитектурных блоков.
2. Разработана математическая модель реструктуризации архитектуры предприятия.
3. Разработан метод оценки качества архитектурной дорожной карты.
4. Разработаны алгоритмы многокритериальной оптимизации архитектурной дорожной карты.
5. Разработан комплекс программ, реализующий предложенные алгоритмы многокритериальной оптимизации архитектурной дорожной карты.
Апробация работы. Основные результаты диссертационной работы докладывались и обсуждались на научно-методическом семинаре факультета бизнес-информатики НИУ ВШЭ для аспирантов и магистрантов «Математическое моделирование, численные методы и комплексы программ» (2012-2014 гг.), международном научном семинаре в Европейском исследовательском центре по информационным системам (ERCIS, г.Мюнстер, Германия, 2012 г.), Конгрессе по интеллектуальным системам и информационным технологиям IS&IT'12 (2012 г.), международной научной конференции International Forum on Strategic Technology (IFOST-2012), международной научной конференции «Инновационное развитие экономики России: региональное разнообразие» (МГУ, 2013 г.), международной научно-практической конференции «Современные информационные технологии и ИТ-образование» (МГУ, 2013 г.), международной конференции S-BPM ONE 2014, the 6th International Conference on Subject-Oriented Business Process Management (Айхштет, Германия, 2014 г.), международной конференции «Математика и информационные технологии в нефтегазовом комплексе» (СурГУ, Сургут, 2014 г.) Полученные в диссертации результаты были использованы в проекте построения архитектуры предприятия для направления деятельности «капитальное строительство» в ОАО «Сургутнефтегаз», а также в лекционных занятиях по дисциплине «Архитектура предприятия» Сургутского государственного университета ХантыМансийского автономного округа-Югры.
Акты внедрения представлены в приложении 7.
Глава 1. Существующие модели и методы планирования архитектурных преобразований информационных систем, архитектура предприятия развилась до дисциплины, оперирующей моделями уровня организации, группы компаний и государства. Как отмечает Е.Зиндер в своей статье [18], сегодня все больше руководителей и аналитиков начинают испытывать потребность в комплексном описании и планировании развития своей организации. Это им нужно как минимум для того, чтобы знать, что их организация представляет собой в реальности, поддерживать рациональный порядок ее устройства, а затем — приступить к ее планомерному развитию или трансформации с учетом всех важных обстоятельств. Таким целям служит «Архитектура предприятия» (АП, Enterprise Architecture) – важнейшая комплексная дисциплина нового времени.
Как правило, архитектура предприятия рассматривается в трех аспектах. Во-первых, как неотъемлемое свойство любого предприятия – его «устройство». Во-вторых, как совокупность моделей, представляющих описание того, как устроено и работает предприятие.
В-третьих, как деятельность, связанная с созданием и использованием архитектурных описаний (как для текущего состояния предприятия, так и для будущего). Более детально суть перечисленных аспектов архитектуры предприятия раскрывается в [42], [15] и [75].
История архитектуры предприятия насчитывает более четверти века (основа дисциплины была заложена Дж.Захманом в 1987 году в его статье “A Framework for Information Systems Architecture” [110]).
Однако на данный момент отсутствует единое общепринятое определение архитектуры предприятия. Согласно обобщенному определению, приведенному в [13], архитектура предприятия – это представляется в некоторый фиксированный момент времени и состоит из трех основных компонентов: миссия, бизнес-архитектура и системная архитектура. В динамическом аспекте описывается процесс желаемому состоянию в будущем.
Архитектура предприятия как основа управления 1.1.
развитием информационных систем крупной компании Значительные вложения в ИТ и возросшая сложность ИТхозяйства ведут к повышению ответственности и роли руководителей, принимающих решения в этой области. Эта ответственность заставляет современных ИТ-директоров и их команды внедрять новые методы управления развитием ИТ, позволяющие сформировать целостный взгляд на информационные системы предприятия.
Одним из таких методов, распространенных в крупных западных компаниях и приобретающих все больше сторонников в России, является методология «Архитектура предприятия» (АП). Эта методология представляет системный подход, позволяющий наладить активное и прозрачное взаимодействие ИТ- и бизнес-служб. В информационных технологий не с позиции обслуживания бизнеса ИТподразделениями, а в рамках партнерских с ним отношений, ведомых едиными целями.
Архитектура предприятия является междисциплинарным подходом, который связан не только с технологическими областями знаний, но также с общей теорией менеджмента, экономикой, социологией, культурой организации, теорией продаж, коммуникаций и т.д. [15].
инструмент управления развитием ИТ, заключается в том, чтобы разработать план использования ИТ-ресурсов бизнес-процессами, а также совокупность принципов управления, позволяющих выразить стратегию бизнеса через ИТ [10]. В этом смысле архитектура моделировании подход к планированию и управлению развитием информационных систем в масштабе организации [81]. При этом объектом моделирования являются не отдельные информационные системы, а предприятие в целом, рассматриваемое как система.
Значение архитектуры предприятия в современных условиях постоянно увеличивается за счет обеспечения возможностей эффективного использования существующих технологий и эволюционного перехода к новейшим технологиям. Фактически АП является одним из наиболее эффективных средств управления изменениями в крупных компаниях, обеспечивая при этом:
оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
предоставление основы для совместной работы бизнесменеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием ИТ-организации в целом;
предоставление единого хранилища всей информации об организации;
обеспечение менеджерам поддержки в принятии решений:
идентифицировать проблемы, выполнять моделирование и т.д. [10].
предприятия» является совокупность теории систем, системного информатики.
Методологический базис строится на основе:
методов теории систем и системного анализа;
методов теории принятия решений;
моделей представления и обработки знаний, систем принятия решений.
методов проектирования и совершенствования архитектуры предприятия (методологии АП);
показателей и методик оценки влияния информационных организаций;
управления бизнес-процессами;
информационных систем.
рассматривается как система. Причем, любое современное крупное предприятие является сложной искусственной системой. Среди задач исследования сложных систем можно выделить два класса [29]:
функционирования системы в зависимости от ее структуры;
2) задачи синтеза, связанные с выбором структуры и значений параметров по заданным свойствам системы.
Задачи анализа сложных систем решаются с использованием множества методов системного анализа. Однако далеко не все эти методы практически применяются в области архитектуры предприятия в силу преследуемых целей, характера создаваемых моделей и уровня их абстракции. Представление предприятия в виде совокупности архитектурных моделей понимается, прежде всего, как способ борьбы с растущей сложностью проблем на стыке бизнеса и информационных технологий, а также сложностью корпоративных информационных систем [15].
В общем, любая модель представляет собой упрощенное представление действительности, которое может быть использовано для описания, обсуждения, анализа исходного объекта и проверки решений. Искусство моделирования состоит в определении нужного компромисса между сложностью модели и ее способностью отражать свойства и поведение исходного объекта [15]. При этом в отношении архитектуры предприятия особенно актуальным является следующее высказывание: «Сложные системы необязательно требуют сложных моделей. Надо стремиться создавать простые модели, они более качественные. Мышление исследователя, разработчика в зависимости от цели моделирования либо формирует модели реально существующих объектов в познавательной деятельности, либо создает идеальные модели еще не существующих систем в задачах проектирования. В тех и других случаях модели должны быть пригодны для решения поставленных задач» [30].
Модели архитектуры предприятия описывают предприятие в двух аспектах: архитектура бизнеса и архитектура информационных технологий. При планировании перехода к целевой архитектуре важно учитывать, что планируемые изменения охватывают не только сферу информационных технологий, но и организацию, в которой эти информационные технологии используются. Поэтому для планирования изменений при переходе к целевой архитектуре предприятия применяются как методы информационного менеджмента, так и методы организационного менеджмента.
предприятия относятся к системным моделям предприятия (рис. 1).
Рисунок 1. Базовые модели предприятий в контексте концептуальных представлений и направлений теории организации и организационных изменений В этой модели главным направлением деятельности менеджеров становится стратегическое управление, а основу построения системотехнический подход.
В системной модели организация представляется в виде взаимодействующей с окружением. Основу модели составляет общая теория систем, главная идея которой заключается в признании взаимосвязей и взаимозависимостей элементов, подсистем и всей системы в целом с внешней средой. В соответствии с этими теоретическими положениями организации рассматриваются как составные части рынка, предопределяющего их структуру и системы управления. Ключевые факторы успеха их деятельности находятся в двух сферах: во внешней (из которой они получают все виды ресурсов, включая информацию) и во внутренней (сильные и слабые стороны которой создают те или иные предпосылки для преобразования ресурсов в продукцию и услуги) [47].
Таким образом, на современных крупных предприятиях архитектура предприятия выступает как эффективное средство управления изменениями, снижения рисков и увеличения отдачи от инвестиций в ИТ. Причина в том, что архитектурные модели четко определяют структуру как существующих, так и будущих ИТ-систем, что приводит к снижению их сложности. А наличие ясной стратегии будущих закупок, выбора поставщиков технологий и планируемых изменений позволяет упростить и ускорить все процессы, связанные с закупками, при одновременном обеспечении совместимости и взаимодействия компонент ИТ-организации [10].
Архитектура предприятия с точки зрения системного 1.2.
организаций, разделяющих определенную миссию, цели и задачи для получения выхода (результата) в виде продукции или услуги. Данное определение соответствуют понятию системы, используемому в системной инженерии.
Согласно ГОСТ ИСО/МЭК 15288:2005 [2] система – это «Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей» (это определение соответствует обобщенному классическому определению понятия «система», приведенному, например в [11] и [39]). Далее ГОСТ уточняет это понятие для искусственных систем следующим образом: «Системы, рассматриваемые в настоящем стандарте, являются искусственными, они созданы и используются с целью предоставления функциональных возможностей в заданных условиях для удовлетворения потребностей пользователей и иных заинтересованных лиц. Эти системы могут состоять из одного или нескольких компонентов: технические средства, программные средства, человеческие ресурсы, процессы (например, процесс оценки), процедуры (например, инструкции оператора), оборудование и природные ресурсы (например, вода, объекты живой природы, минералы). Фактически системы являются результатами реализации замысла в виде получаемой продукции или услуг».
В соответствии с [29], сложной системой называется система, состоящая из разнотипных элементов с разнотипными связями.
Таким образом, современное крупное предприятие можно рассматривать как сложную искусственную систему.
Применительно к системе в ГОСТ Р ИСО 15704-2008 [1] архитектура определяется как «Описание (модель) основного устройства (структуры) и связей частей системы (физического или концептуального объекта или сущности)».
«Архитектура – это многоаспектное описание или план задуманной воплощением, а также принципы и руководящие материалы, определяющие руководство конструированием и развитием системы во времени». Это определение базируется на международном стандарте ISO/IEC/IEEE 42010:2011 [57].
Более подробно понятие архитектуры системы рассматривается в [5]. В частности, приводится следующее определение:
«Архитектура системы определяется как общая логическая организация системы, дающая о ней целостное представление и определяемая ее 1) конфигуратором, 2) иерархическими аспектными подсистемами, межуровневого, так и межаспектного».
Под «конфигуратором» понимается «набор различных языков системного анализа данной проблемы» [37].
Основные общие рекомендации по созданию архитектурных описаний, применимых для архитектуры предприятия, закреплены стандартом организации IEEE (The Institute of Electrical and Electronics Engineers) IEEE Std 1471-2000 [56].
Для архитектуры предприятия языки, аспекты и уровни описания закрепляются «рамочными моделями» (frameworks) и методологиями АП. Архитектурная рамочная модель (architecture framework) определяется стандартом ISO/IEC/IEEE 42010 – 2011 [57] как «соглашения и общие практики описания архитектуры, установленные внутри определенной области деятельности или сообщества заинтересованных лиц». Также в данном стандарте описаны требования к архитектурным рамочным моделям: «рамочная модель должна определять: круг заинтересованных лиц, набор представления, очерчивающие эти проблемы (т.е. предназначаемые для их решения)» [74].
Таким образом, архитектура предприятия, как область знаний, базируется на методах системного анализа и предлагает специальные модели и методы, ориентированные на рассмотрение предприятия как сложной искусственной системы.
Модели архитектуры предприятия 1.3.
Как правило, архитектура предприятия принимает форму достаточно обширного набора моделей, которые описывают структуру и функции предприятия [15]. Цели создания моделей при описании архитектуры предприятия и применяемые средства разнообразны, так же разнообразны и создаваемые модели. Однако наличие общих черт позволяет сгруппировать модели в отдельные классы, что облегчает и упорядочивает их разработку и изучение.
В теории моделирования рассматривается много признаков классификации и их количество не установилось. Тем не менее, наиболее актуальны следующие признаки классификации [8], [17], [46], [4]:
способ реализации модели;
форма представления модели;
целевое назначение модели (характер моделируемой стороны характер процессов, протекающих в объекте.
Модели архитектуры предприятия представляются в форме схем, диаграмм, матриц, списков (каталогов), таблиц, а также текстовых описаний. По способу реализации модели АП являются идеальными и знаковыми. При этом многие методологии архитектуры предприятия различают формальное и неформальное моделирование.
При формальном моделировании создаются строго формализованные модели и их представления (графы, иерархии, таблицы, матрицы), которые можно отнести к подклассу математических моделей. При неформальном моделировании, как правило, создаются описательные модели в произвольной форме (тексты, рисунки). Текстовые описания относятся к подклассу лингвистических моделей, а рисунки – к подклассу графических (рис. 2).
Рисунок 2. Место моделей АП в классификации моделей Математические модели по форме представления принято делить на структурные и функциональные.
Модель является структурной, если она представима структурой данных или структурами данных и отношениями между ними [17].
взаимоотношений сущностей данных [34].
Модель функциональная, – если она представима в виде системы функциональных соотношений. Например, закон Ньютона и модель производства товаров – функциональные [17].
Строго говоря, при построении архитектуры предприятия не используются функциональные модели, поскольку не используются и функциональные соотношения. Однако функциональные модели могут быть представлены в графическом виде (блок-схема процесса функционирования системы, диаграмма потока работ). Поэтому в области моделирования и системного анализа также используются термины «структурно-функциональная модель» и «структурнофункциональное моделирование» [30].
По целевому назначению модели подразделяются на модели структуры, функционирования и стоимостные (модели расхода ресурсов) [4]. Все три названных класса широко применяются в архитектуре предприятия.
Модели структуры отображают связи между компонентами объекта.
знаковых моделей, например:
процессы существования системы от зарождения замысла ее создания до прекращения функционирования;
модели операций, выполняемых объектом;
информационные модели, отображающие во взаимосвязи источники и потребители информации;
взаимодействия элементов исследуемого объекта.
Стоимостные модели, как правило, сопровождают модели функционирования объекта и по отношению к ним вторичны, «питаются» от них информацией и совместно с ними позволяют проводить комплексную технико-экономическую оценку объекта или его оптимизацию по экономическим критериям [4].
При моделировании архитектуры предприятия, как правило, используются архитектурные методологии и рамочные модели, которые не только содержат рекомендации по типам создаваемых моделей, но и систематизируют их по предметным областям (доменам) и слоям. Общим для большинства методологий и рамочных моделей АП является выделение следующих трех слоев (рис. 3):
корпоративные миссия и стратегия (стратегические цели и задачи);
бизнес-архитектура;
системная архитектура.
Корпоративные миссия и стратегия определяют основные направления развития организации и ставят долгосрочные цели и задачи.
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые бизнес-модель, бизнес-процессы, информационные и материальные потоки, а также поддерживающую их организационно-штатную структуру.
методологических, технологических и технических решений для обеспечения информационной поддержки деятельности организации, архитектуру приложений, архитектуру данных и техническую архитектуру [10].
Основой современных подходов к построению бизнес-слоя и системного слоя архитектуры являются методологии структурного и объектно-ориентированного анализа и проектирования [10].
Структурным анализом принято называть метод исследования системы, при котором исследование начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для методов данного класса характерно:
разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней;
ограниченный контекст, включающий лишь существенные на каждом уровне детали;
использование строгих формальных правил записи;
последовательное приближение к конечному результату.
Все методологии структурного анализа базируются на ряде общих принципов, регламентирующих организацию работ по используются следующие: принцип «разделяй и властвуй» и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения на множество меньших независимых задач, легких для понимания и решения. Второй принцип в дополнение к тому, что легче понимать систему, когда она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимаемость системы резко повышается при организации ее частей в древовидные иерархические структуры, т.е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Важным моментом облегчения понимаемости сложных систем является широкое использование структурными методами графических нотаций.
Для целей структурного анализа и проектирования традиционно используются три группы средств, иллюстрирующих:
функции, которые система должна выполнять (более точно – функциональную структуру системы, последовательность выполняемых действий, передачу информации между элементами функциональной структуры);
отношения между данными;
динамическое поведение системы.
Среди всего разнообразия графических нотаций, используемых для решения первой задачи, в структурных методологиях наиболее часто и эффективно применяемыми являются следующие:
DFD (Data Flow Diagrams) [84], [48] – диаграммы потоков данных совместно со спецификациями процессов нижнего уровня (мини-спецификациями);
SATD (Structured Analysis and Design Technique) [31] – диаграммы (точнее, их стандартизованное подмножество – модель IDEF0) – используются для моделирования бизнесслоя архитектуры;
модели IDEF3 (Process Description Capture Method) [82] и EPC (Event-Driven Process Chain) [59], [96] – для моделирования Наиболее распространенным средством моделирования отношений между данными (информационного моделирования) является диаграмма «сущность - связь» (Entity-Relationship Diagram ERD) [34], известная в двух нотациях – Чена [68] и Баркера [58]. ERD традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области.
традиционно применяется диаграмма переходов состояний (State Transition Diagram – STD) [78], описывающая множество системных состояний и определяющая перемещение моделируемой системы из одного состояния в другое.
Важное место в разработках архитектурных моделей занимают объектно-ориентированные методологии, основанные на объектной декомпозиции предметной области. Объектно-ориентированный подход заключается в представлении моделируемого процесса в виде Большинство современных методов объектно-ориентированного подхода основано на использовании унифицированного языка моделирования (Unified Modeling Language – UML) [106] – фактического преемника наиболее распространенных методов Буча, Рамбо и Якобсона.
Методы планирования архитектурных преобразований 1.4.
процесс последовательного изменения архитектуры предприятия от ее текущего (базового) состояния к желаемому (целевому) состоянию. В используются термины «внедрение целевой архитектуры», «миграция архитектуры предприятия» или «переход от базовой архитектуры к целевой».
Планирование архитектурных преобразований, как правило, подразумевает выполнение следующих пяти шагов:
(формирование базовой архитектуры).
(формирование целевой архитектуры).
3. Сравнение базовой и целевой архитектур предприятия и выявление различий (gap-анализ).
4. Создание архитектурной дорожной карты на основе данных gap-анализа.
архитектурной дорожной картой.
методологий, наиболее развитые из которых содержат общую рамочную модель (framework), описание процесса разработки и внедрения архитектуры, а также набор необходимых шаблонов.
Существует ряд источников (например, [73], [107]), в которых приводится сравнение ведущих архитектурных методологий.
Ниже приведены краткие описания методологий и рамочных распространение. Особое внимание уделяется наличию в них методов планирования архитектурных преобразований.
предложенная Дж.Захманом. Она представляет из себя матрицутаксономию, в которой в формализованном виде представляется модель организации с разных точек зрения (планировщика, владельца, конструктора, разработчика и пользователя). Также задается набор типов моделей, которые должны использоваться для ячеек матрицы.
Эта модель изначально была разработана для представления формализована и расширена для использования при моделировании архитектуры предприятия.
Zachman Framework, хотя и является одной из наиболее популярных рамочных моделей, но не имеет описания процесса построения и внедрения архитектуры [109].
Federal Enterprise Architecture Framework (FEAF) [69] – архитектурная методология, используемая правительством США для улучшения взаимодействия между министерствами. В основе подхода FEAF лежит унификация и выравнивание бизнес-функций и поддерживающих функций информационных систем посредством единого набора референсных моделей. Методология содержит как архитектурных областей, так и описание архитектурного процесса.
оригинальное сочетание общего централизованного руководства и децентрализованного планирования при реализации архитектур отдельных организаций (а тем более – отдельных ИС). Одно из полезных положений FEA – принцип сегментного подхода – дает возможность ускорять практическое внедрение АП, особенно в больших многоотраслевых образованиях, позволяя относительно независимо работать в рамках одного сегмента, обеспечивая минимизацию затрат, поддержку общих ресурсов и стандартов взаимодействия систем разных сегментов. FEAF включает и другие ценные методические документы, например, по управлению инвестициями, по оценке зрелости архитектуры [19].
описание процесса внедрения целевой архитектуры, охватывающее, в том числе, и управление проектами. Однако описание процесса не содержит детальной методики планирования изменений.
Перечисляются только основные шаги для формирования плана миграции и факторы, которые необходимо при этом учитывать. В частности, указывается на необходимость выявления зависимостей информационных систем при внедрении промежуточных архитектур, а также на балансировку преимуществ и рисков отдельных проектов.
Methodology (GERAM) [60], [79] – обобщенная методология архитектуры предприятия, созданная для целей интеграции предприятий и инжиниринга бизнес-процессов. Методология GERAM предназначена для моделирования всего жизненного цикла проекта предпринимателей, которые изначально ее разработали. На следующих этапах выполняется функциональное проектирование, детальное проектирование и физическое внедрение разработанного проекта. GERAM содержит методики, модели и инструменты, которые необходимы для построения интегрированной организации, будь она частью предприятия, отдельным предприятием или сетью предприятий.
Рамочная модель GERAM предусматривает:
названных представлениями (Views), – типы моделей («функции», «данные», «ресурсы», «организация»), назначения, реализации и «физические представления» (аппаратура, ПО);
описание всех аспектов или какой-то их части на каждой из фаз формирования архитектуры и функционирования предприятия;
конкретизацию модели архитектуры на трех уровнях — используемые референсные, reference) и конкретных моделей.
Особенность GERAM состоит в том, что ось фаз развития архитектуры в принципе может отражать ход времени и не связана жестко с представлениями разных участников процесса, а также в том, что в явной форме введено понятие референсной архитектуры и модели. Для представления развивающейся АП минусы этой схемы таковы:
проектного цикла локальных систем, но, потенциально допуская итерации реинжиниринга предприятия, она недостаточно явно соответствует спиральной форме истории жизни предприятия в реальном времени его развития;
структура схемы и ее описание, похоже, оказались слишком сложными, формальными и жесткими для восприятия практиками, в результате чего GERAM, оставаясь частью стандарта ISO 15704:2000, в широкой практике не получила заметного распространения [18].
Кроме того, в описании методологии GERAM внедрение (Implementation) обозначено только в качестве фазы архитектурного процесса. При этом методика внедрения отсутствует.
Архитектурная методология META Group – одна из закрытых методологий, описание которой предоставлялось только клиентам компании (в 2005 году META Group была поглощена компанией Gartner). По мнению архитекторов организации META Group, "архитектура является одновременно некоторым структурированным описанием управленческих технологий предприятия и его ИТ (т.е.
конечным результатом, включающим определенные артефакты, стандарты, утверждения, касающиеся общего видения, архитектурные документы), процессом создания и обновления артефактов архитектуры и группами людей, вовлеченных в этот процесс".
Соответственно этим представлениям методика компании уделяет достаточно подробное внимание всем трем составляющим архитектуры.
Отличительной особенностью методики META является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих [22], однако это описание недоступно для изучения, поскольку является в настоящее время интеллектуальной собственностью компании Gartner.
Архитектурная методология Gartner – одна из закрытых методологий, детальное описание которой не представлено в методология Gartner представляет собой в основном набор лучших практик и шаблонов. Модель Gartner сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:
Среда бизнес-взаимодействия (Business Relationship Grid);
Бизнес-процессы и стили бизнес-процессов;
Технологические строительные блоки (кирпичики - bricks).
Данный подход Gartner представляет собой пример реализации методологии достаточно высокого уровня. Он задает только общую рамочную модель описания и фактически не определяет ни форматов, ни какого-либо специализированного языка для описания. Что последовательности шагов и задач участников, которые, однако, не детализированы до уровня моделей процесса разработки архитектуры [15].
Планирование архитектуры предприятия) является одной из наиболее известных методик формирования архитектуры предприятия [101]. Она разработана Стивеном Спиваком в 1992 году.
Методика ЕАР (рис. 4) не содержит собственной рамочной модели, но обеспечивает высокоуровневый взгляд на предприятие с информации. Это инструмент планирования, а не детального проектирования или моделирования архитектуры. Результаты планирования используются в качестве основы для интегрированной разработки прикладных систем и технологий, которые обеспечивают потребности бизнеса. Отличительными характеристиками этого подхода к планированию архитектуры являются следующие:
в основе - потребности бизнеса, а не технологические факторы; основное внимание сосредоточено более на данных и потребностях в информации, чем на процессах;
ответственность за процесс в большей степени несут представители бизнес-подразделений, чем специалисты по архитектуры Захмана, то можно сказать, что методика ЕАР является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. это перспективы, соответствующие представлениям об архитектуре бизнес-руководителей:
«планировщика» и «владельца» [15].
ориентировался на планирование именно информационных систем.
При этом EAP представлялся как процесс, определяемый бизнесом или данными, поскольку:
устойчивая бизнес-модель;
данные (понимаемые как бизнес-информация, описываемая в стиле «сущности-связи») определялись до определения приложений;
внедрения прикладных систем.
Привязка EAP к стабильности бизнес-модели, а также к подходу, «управляемому данными», во многом ограничивает применение EAP в сегодняшних условиях [18].
The Open Group Architecture Framework (TOGAF) [105] – архитектурная методология некоммерческой организации “The Open Group”. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение - ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В состав модели TOGAF входят две основные компоненты - методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML [15].
Методика TOGAF ADM состоит из достаточно подробно описанных девяти фаз (одной предварительной и восьми основных – от A до H), рис. 5. В целом методика TOGAF ADM аналогична методике Enterprise Architecture Planning, предложенной Стивеном Спиваком [101]. При этом фазы планирования миграции (E и F) содержат описание подходов к планированию архитектурных изменений, а также входных и выходных данных.
Разработка TOGAF считается наиболее важным вкладом в развитие архитектуры предприятия из-за предложенной гибкости, а также заложенных в эту методологию средств поддержки верификации архитектуры [73].
В настоящее время на практике в большинстве случаев применяются: Zachman Framework, FEAF, TOGAF и методология Gartner ( [99], [15], [10]).
При описании планирования процесса реструктуризации архитектуры предприятия в TOGAF, как и во многих других методологиях, большое значение придается необходимости учитывать зависимости [104]: «Существует несколько типов зависимостей, которые должны приниматься во внимание, такие как зависимости от информационных сервисов или их изменений. Зависимости должны использоваться для определения последовательности внедрения и идентификации необходимых координирующих действий. Изучение зависимостей позволяет группировать мероприятия, создает базис для формирования проектов. При проверке зависимостей релевантных проектов может быть выстроена логическая последовательность их реализации. Зависимости также помогают определить, когда выявленные шаги могут быть выполнены. Выявление и использование зависимостей служит базисом для планирования миграции».
Анализ специальной литературы в области архитектуры предприятия [97], [15], [10], [13], [93], [90], [77], [83], [87], [70] показывает, что в подобных источниках, как правило, содержатся обзорные описания наиболее развитых методологий, перечисленных выше, а также подходы к моделированию, обсуждаются различные аспекты применения архитектуры, трудности взаимодействия с заинтересованными лицами, организация проектов построения АП.
Однако в такой литературе крайне мало внимания уделяется планированию внедрения целевой архитектуры и не предлагается соответствующих методологиях).
Например, в книге “How to Manage the Enterprise Architecture Practice” [97] автором описывается общий для многих источников подход:
«Преобразование предприятия в соответствии с целями и условиями, описанными его целевой архитектурой, невозможно реализовать в один шаг. Изменение предприятия от его базовой архитектуры к целевой требует проведения множества параллельных независимых мероприятий, и это изменение выстраивается пошагово.
Лучшим способом понимать и контролировать этот сложный эволюционный процесс является разработка и поддержка «дорожной преобразований должен обеспечить пошаговый процесс перехода от базовой к целевой архитектуре предприятия.
Первым шагом в планировании преобразований является так называемый gap-анализ (или анализ несоответствия) – выявление различий между базовой и целевой архитектурами предприятия. При этом выделяются критические различия, то есть те из них, которые влияют на успешное выполнение миссии предприятия. Кроме того, gap-анализе осуществимость.
Посредством gap-анализа команда архитекторов предприятия может определить компоненты, которые должны быть изменены для достижения желаемого целевого состояния. Различие между текущим и целевым состоянием архитектуры предприятия преодолевается серией последовательных преобразований. Размер отдельных преобразований зависит от множества факторов: общее время между текущим и целевым состоянием, зависимости между программами развития и компонентами, критические пути для мероприятий с высокой зависимостью, бизнес-приоритеты (например, решения органов власти и директивы руководства), ограничения человеческих ресурсов для управления отдельными проектами преобразований, ожидаемый возврат на инвестицию от проектов, а также риски. При выполнении gap-анализа оценивается состояние устаревших систем, зрелость технологий, возможности при приобретении других компаний и финансовая реальность преобразований.
Ключом к приоритезации мероприятий и проектов является преобразование изменений в бизнесе, прекращение эксплуатации систем, постепенное упразднение функциональности, график внедрения новых систем, технологий и новой системной функциональности на предприятии».
Модели и методы формирования портфеля проектов 1.5.
Многие источники в области архитектуры предприятия (в частности, [69], [60], [104], [97],) ссылаются на необходимость применения методов управления проектами и портфелем проектов при реализации архитектурных преобразований на предприятии. При этом следует заметить, что формирование архитектурной дорожной карты относится к «допроектному» этапу процесса преобразований:
архитектурная дорожная карта служит исходной информацией для формирования портфеля ИТ-проектов, предварительно (на стратегическом уровне) определяя необходимую последовательность их выполнения. В то же время, при формировании портфеля проектов также решаются задачи выбора последовательности проектов.
Задачи формирования портфеля проектов можно разделить на два больших класса: однокритериальные и многокритериальные.
Однокритериальные модели принятия решений об отборе проектов в портфель по учету неизвестных факторов можно подразделить на детерминированные, стохастические и модели с элементами неопределенности [32].
Существующие модели формирования портфеля, реализуемые в условиях определенности, а также в зависимости от вида целевой функции и ограничений можно разделить на четыре вида: 1) линейные, 2) нелинейные, 3) динамические и 4) графические [50].
В [53] приведена классификация моделей, с использованием которых возможно формирование портфеля проектов (рис. 6).
Рисунок 6. Классификация однокритериальных моделей формирования портфеля Наибольшим разнообразием отличается группа линейных моделей. В линейных моделях целевая функция и ограничения линейны по управляющим переменным. На сегодняшний день наиболее известны следующие линейные модели [53]:
• задача о ранце;
• статическая модель Дина;
• одноступенчатая модель Альбаха;
• многоступенчатая модель Хакса и Вайнгартнера;
• модель с несколькими производственными ступенями – расширенная модель Ферстнера-Хенна;
• модель с возможностями выбора установок и дезинвестиций Якоба.
Авторами нелинейных моделей являются Бумба, МентценШольц, Якоб, Дитхл, Петерс и др. Динамические модели были разработаны Вагнером, Лайером, Зеелбахом.
модификациями сетевых моделей.
формирования портфеля является их относительная простота. Но однокритериальные модели не отражают многоцелевой сущности проектов и портфелей проектов. Таким образом, такое преимущество однокритериальных моделей одновременно является и их основным недостатком. Однокритериальные задачи формирования портфеля не отражают синергетического эффекта портфеля проектов.
Синергетический эффект портфеля проектов, в частности, экономических, финансовых, социальных и др. конечных результатов.
Под эффектом синергизма портфеля проектов понимается ситуация, когда получаемая полезность от реализации портфеля проектов превышает полезность от реализации проектов портфеля по отдельности.
В [53] предлагается описывать все синергетические эффекты тремя переменными: увеличение прибыли, снижение издержек, уменьшение потребности в инвестициях и динамику изменения этих переменных. Таким образом, общий синергетический эффект можно было бы выразить посредством роста величины денежных потоков (или нормы возврата капитала).
многокритериальность оценки результатов отдельных проектов, так как стратегические цели организации обычно описываются векторным критерием.
На современном этапе развития задач формирования портфелей проектов наибольшее распространение получили задачи оптимизации портфеля по критериям «риск-доходность». В частности, подробно двухкритериальная задача оптимизации портфеля по критериям многокритериальной задачи формирования портфеля проектов приведена в [53].
При формировании архитектурной дорожной карты основной задачей является задача выбора последовательности проектов. Этот последовательности выполнения (точнее – моментов времени начала выполнения) фиксированного множества независимых проектов.
упущенной выгоды и самофинансирования.
Таким образом, существующие модели и методы формирования портфеля проектов могут быть использованы для выстраивания последовательности проектов архитектурной дорожной карты, однако это потребует значительного объема дополнительных исходных данных, которые, как правило, отсутствуют на соответствующем этапе архитектурного процесса.
Метод построения архитектурной дорожной карты TOGAF 1.6.
описание процесса планирования архитектурных изменений содержится в составе методологии TOGAF. База данных ресурсов TOGAF содержит необходимые для этого шаблоны в виде таблиц и планирования архитектурных изменений TOGAF.
Одними из центральных понятий процесса планирования изменений в TOGAF ADM являются «архитектурная дорожная карта»
и «архитектурный блок».
TOGAF выполнения работ, при помощи которых осуществляется переход к целевой архитектуре предприятия. Цель составления архитектурной архитектуры предприятия. Эта последовательность состоит из «пакетов работ», включающих создание новых или исключения существующих архитектурных блоков на соответствующих этапах архитектурной дорожной карты.
Архитектурный блок (или архитектурный строительный блок – Architecture Building Block) TOGAF – это составная часть архитектуры предприятия [103]. Архитектурный блок отражает набор функциональности1, необходимой для удовлетворения потребностей бизнеса в масштабе организации в целом [103], [105].
дальнейшего детального планирования работ по переходу к целевой архитектуре предприятия.
Согласно методике TOGAF ADM планирование внедрения Следует отметить, что в контексте архитектуры предприятия «функциональность»
является достаточно широким понятием, включающим как бизнес-процессы, так и функции приложений или технологических подсистем.
«F. Планирование миграции» (Migration Planning) [104].
Фаза «E. Возможности и решения» представляет собой начальный шаг создания плана внедрения и миграции, на котором разрабатывается начальная версия архитектурной дорожной карты.
Процесс формирования архитектурной дорожной карты и плана внедрения и миграции на фазе E согласно TOGAF ADM состоит из следующих шагов:
1. Определение и подтверждение ключевых корпоративных атрибутов изменений.
Выявляются и документируются при помощи «Матрицы оценки факторов внедрения» (табл. 1) факторы, которые могут повлиять на внедрение целевой архитектуры предприятия. Эти факторы, как правило, включают: риски, проблемы, предположения и зависимости, а также необходимые мероприятия. Выводы, отражаемые в этой матрице, описывают, каким образом архитектура предприятия может быть наилучшим образом внедрена в контексте его организационной культуры.
Таблица 1. Матрица оценки факторов внедрения 2. Определение бизнес-ограничений для внедрения.
Выявляются и описываются любые потенциальные влияния со стороны бизнеса, которые могут ограничивать последовательность корпоративном уровне, так и на уровне отдельных направлений деятельности).
предыдущих фаз (от B до D).
Консолидируются результаты gap-анализа (анализа различий архитектурных моделей базовой и целевой архитектур; различия представляются в виде архитектурных блоков). Вырабатываются потенциальные варианты решений, соответствующих выявленным различиям, описываются их взаимозависимости. Результаты различий, решений и зависимостей» (табл. 2).
Архитектурные Таблица 2. Консолидированная матрица различий, решений и зависимостей В целях дальнейшей группировки работ в проекты выявляются требования, которые могут удовлетворяться одними и теми же компонентами целевой архитектуры (например, несколько требований разных направлений деятельности могут быть удовлетворены через обеспечение совместно используемых новых бизнес- и ИТ-сервисов).
5. Консолидация и согласование требований к взаимодействию.
архитектурных блоков в отсутствии исключаемых (на основе «Консолидированной матрицы различий, решений и зависимостей»).
Результатом могут быть ограничения на последовательность внедрения и исключения архитектурных блоков, а также создание новых архитектурных блоков.
6. Уточнение и проверка зависимостей.
архитектурными изменениями и существующими на предприятии планами. Эти зависимости далее используются при определении последовательности внедрения и координации проектов.
7. Подтверждение готовности бизнеса к трансформации и сопутствующим рискам.
Задачей данного шага является уточнение, классификация и смягчение рисков, связанных с трансформацией бизнеса (выявляются на фазе A). Эти риски также документируются при помощи «Консолидированной матрицы различий, решений и зависимостей».
8. Формулирование стратегии внедрения и миграции.
В целях дальнейшего формирования пакетов работ определяется стратегия внедрения целевой архитектуры. При этом сначала выбирается общий стратегический подход к внедрению решений.
Существует три базовых подхода: «В чистом поле» (Greenfield) – полностью новое внедрение, «Революционный» и «Эволюционный».
Далее в рамках выбранной стратегии выбирается подход, который позволит смягчить риски, описанные в «Консолидированной матрице различий, решений и зависимостей». Наиболее распространенные подходы: «Быстрые победы», «Достижимые цели» и «Метод цепочки добавленной стоимости».
9. Идентификация и группировка основных пакетов работ.
«Консолидированной матрицы различий, решений и зависимостей».
Далее описанные решения логически группируются в пакеты работ с учетом «Матрицы оценки факторов внедрения» и выбранного подхода к внедрению. Затем пакеты работ группируются в портфели и проекты внутри портфелей с учетом зависимостей и стратегии внедрения.
10. Идентификация транзитных архитектур.
Транзитные (или промежуточные) архитектуры выделяются, когда необходим инкрементальный подход для соответствия способности организации к выполнению и принятию изменений.
Исходными данными служат «Консолидированная матрица различий, Идентифицируются потенциально «трудные» мероприятия, которые по возможности планируются для более позднего внедрения (по сравнению с мероприятиями, легко обеспечивающими предприятию отсутствующие возможности). При формировании транзитных архитектур также учитывается выбранная стратегия внедрения.
11. Создание архитектурной дорожной карты и плана внедрения и миграции.
На основе требований заинтересованных лиц, информации о готовности бизнеса к изменениям, описании возможностей, решений консолидируются в архитектурной дорожной карте. Дорожная карта описывает последовательность изменений при переходе от базовой архитектуры к целевой. Это описание используется для формирования плана внедрения и миграции, который состоит из мероприятий, необходимых для реализации архитектурной дорожной карты.
В TOGAF ADM указывается на существование множества последовательность, определяемая данными (сначала внедряются приложения, которые создают данные, а затем – приложения, которые эти данные используют). Также для эффективного планирования внедрения и миграции необходимо четкое понимание зависимостей и жизненного цикла существующих на предприятии информационных систем.
Созданные на фазе E архитектурная дорожная карта и проект плана внедрения и миграции уточняются на фазе «F. Планирование миграции» совместно с управленческими структурами предприятия, менеджерами портфеля и проектов. При этом выполняется приоритезация пакетов работ, присвоение показателей бизнесценности, интеграция с другими изменениями на предприятии, оценка затрат и преимуществ от проектов миграции в контексте деятельности организации, а также продолжительности проектов и требований к ресурсам.
формирования и планирования проектов внедрения целевой архитектуры.
Приведенное краткое описание фаз E и F TOGAF ADM показывает, что методология TOGAF не предлагает формальных методов планирования перехода от базовой архитектуры предприятия к целевой. Процесс формирования архитектурной дорожной карты, а также плана внедрения и миграции остается в основном творческим.
Выбор стратегии, подходов к внедрению и последовательности мероприятий будет зависеть от опыта, интуиции и личных предпочтений архитекторов. При этом существует множество вариантов архитектурной дорожной карты и, соответственно, плана внедрения и миграции, обоснование выбора которых остается за рамками методологии TOGAF.
Тем не менее, на фазе E TOGAF ADM (шаги с 1 по 10) создаются структурированные данные, включающие:
факторы, влияющие на внедрение, – «Матрица оценки факторов внедрения» (табл. 1);
блоки базовой архитектуры и внедряемые архитектурные зависимостей» (табл. 2);
Кроме того, в «Консолидированной матрице различий, решений и зависимостей» приведено текстовое описание зависимостей между изменениями и факторами, которые могут быть использованы для формализации зависимостей.
В целях создания эффективного плана внедрения и миграции при обеспечении объективности принимаемых решений необходимо для шага 11 («Создание архитектурной дорожной карты и плана внедрения и миграции») фазы E TOGAF ADM разработать формальные методы, позволяющие выстраивать последовательность изменений на основе перечисленных структурированных данных.
Далее последовательность изменений, полученная при помощи формальных методов, может использоваться для обоснованного формирования архитектурной дорожной карты и плана внедрения и миграции.
1.7.
предприятия показывает, что большинство методологий архитектуры предприятия не содержат формальных методов планирования архитектурных изменений.
Наиболее детально метод планирования перехода от базовой архитектуры предприятия к целевой описан в методике TOGAG ADM.
Благодаря базе данных ресурсов и подробному описанию архитектурного процесса, TOGAF является на сегодняшний день наиболее полной с точки зрения практического использования и наиболее формализованной методологией. Аналогичные выводы предприятия [73], [107]. В том числе в TOGAF ADM подробно описывается процесс планирования изменений при переходе от базовой архитектуры предприятия к целевой, а база данных ресурсов TOGAF содержит соответствующие шаблоны в виде таблиц и матриц.
Другие архитектурные методологии либо не содержат описания процесса планирования архитектурных изменений, либо (как, например, FEAF) ограничиваются поверхностным описанием шагов, которые необходимо выполнить.
Тем не менее, ни в TOGAF, ни в других методологиях не зависимости между элементами архитектурных моделей, а также другими факторами, и в целом процесс построения архитектурной дорожной карты является неформальным.
Как отмечается в [15], для описания архитектур существует множество различных методик и вариантов, отличающихся группировкой рассматриваемых понятий. Для упорядочения выполняемых работ предложены специальные методы - например, процесс разработки архитектур, описанный выше TOGAF ADM.
Казалось бы, что разработка архитектуры в этих условиях будет являться достаточно простым, повторяемым и рутинным процессом.
На самом деле, в этих рассуждениях опущено одно очень важное проектирования архитектуры по необходимости должен являться творческим. Этот вывод касается как формирования целевой архитектуры предприятия, так и планирования соответствующих, зачастую весьма масштабных, изменений.
Таким образом, методологии и рамочные модели архитектуры предприятия выступают в настоящее время как мощный инструмент управления изменениями на предприятии и, прежде всего, управления развитием его информационных систем. При этом в литературе по архитектуре предприятия часто указывается на необходимость планирования реструктуризации архитектуры с учетом зависимостей, однако не приводится строгих методов, позволяющих эффективно реализовать это указание на практике.
Следовательно, для повышения эффективности планирования архитектурных преобразований необходима разработка формальных моделей и методов, учитывающих зависимости между элементами архитектурных моделей и позволяющих объективно оценивать различные варианты архитектурных дорожных карт.
Глава 2. Модель реструктуризации архитектуры Планирование технологических и организационных 2.1.
изменений предприятия на основе теории комплементарных взаимодействий В рамках теории комплементарных взаимодействий (Theory of Complements), разработанной П.Милгромом и Дж.Робертсом [33], производительность предприятия в целом и результат использования деятельности (activities) предприятия друг другу и, как следствие, «мощностью» комплементарных взаимосвязей между ними. Наличие таких взаимодействий и их влияние на производительность подтверждено рядом эмпирических исследований, как в анализе отдельных примеров, так и в эконометрических расчетах на больших выборках фирм [65], [63].
Согласно [33] комплементарность приводит к образованию деятельности. Милгром и Робертс дают следующее определение комплементарности: «Несколько видов деятельности считаются комплементарными (или взаимодополняющими), если увеличение объема любого из них увеличивает предельную прибыльность каждого из всех остальных видов деятельности». Аналогично, виды взаимоослабляющими), если увеличение объема любого из них уменьшает предельную прибыльность каждого из всех остальных видов деятельности.
Явления комплементарности обычно приводят к множеству возможных согласованных соотношений элементов, т.е. к множеству в равной степени устойчивых систем с различающейся структурой.
Внутри каждой такой системы различные стратегии, ресурсы, процессы и элементы организационной структуры взаимно поддерживают друг друга, и в конкретной среде один вариант может быть более эффективен, чем другой. Однако смешение элементов двух различных устойчивых систем с большой вероятностью вызовет несоответствие, которое приведет к резкому падению эффективности.
Именно поэтому переход от одной системы к другой неизбежно сопряжен с кризисом. Близкий всем российским читателям пример – переход от советской системы к рыночной. При всех очевидных недостатках элементы плановой системы имели высокую степень специфической именно для нее комплементарности. Внедрение в эту систему отдельных механизмов самоорганизации не улучшило, а резко ухудшило состояние экономики [52].
рассматриваются комплементарные взаимодействия организационных практик. Организационная практика – понятие, боле широкое, чем вид деятельности. Организационная практика (или просто «практика») рассматриваются, например, виды деятельности или бизнес-процессы, использование определенного оборудования, автоматизированных систем, методик учета затрат или способов оплаты труда.
Согласно [67] две практики считаются комплементарными, когда отдача от внедрения одной из них становится больше, если другая практика уже присутствует в организации. Например, отдача от внедрения определенной компьютерной системы может быть выше в присутствии обучения, чем если бы обучения не было. Точно так же, компьютерной системы, чем при ее отсутствии.
Как можно описать и проанализировать взаимосвязи различных организационных практик компании друг с другом, с ИТ-сервисами и со свойствами человеческого капитала? Для описания бизнеспроцессов, организационной структуры, архитектуры информационных систем и данных в настоящее время разработан целый ряд моделей, широко применяемых как самостоятельно, так и при формировании архитектуры предприятия. Однако, как отмечают авторы [28], на сегодняшний день существует лишь одна модель, решающая задачу описания взаимосвязей между практиками предприятия – матрица изменений. Она была предложена Э.Бринйолфссоном и соавторами в работе «Матрица изменений» [66], [52] (рис. 7).
Матрица изменений базируется на хорошо известном в области управления качеством инструменте, называемом «структурирование функции качества», или, более образно, «дом качества». Эрик Бринйолфссон несколько изменил этот подход, приспособив его для анализа взаимосвязей между практиками компании.
Матрица изменений состоит из двух частей – таблиц, прямоугольной части – списка организационных практик и треугольной, содержащей данные о взаимосвязях между практиками.
Знак «+» в ячейках треугольника означает, что соответствующие практики являются взаимодополняющими, знак «» – что эти практики взаимно ослабляют друг друга. Горизонтальная таблица содержит существующие на предприятии практики (на рис. 7 – «Текущие практики»), вертикальная – практики, внедряемые в ходе проекта (на рис. 7 – «Целевые практики»). Данные о взаимодействии организационных практик заполняются на основе экспертных оценок сотрудников организации. Строка и столбец «Важность» описывают важность внедряемых практик по шкале Ликерта (от -2 – «очень мешает» до +2 – «очень важна»). Соответствующие оценки также получаются на основе опроса экспертов. Наконец, прямоугольник на пересечении двух таблиц описывает комплементарность существующих и внедряемых практик и, соответственно, трудности перехода от «как есть» к «как будет» [45].
визуально-интуитивный инструмент, который помогает ответить на следующие типы вопросов [54]:
последовательна существующая организация бизнес-процессов компании? Насколько устойчивой будет планируемая организация?
Насколько трудным может быть переход от одной системы к другой?
2. Последовательность выполнения изменений. С чего должны начаться изменения? Какая последовательность изменений будет успешной? Имеются ли точки, в которых возможно остановить изменения?
компания прибыль от произведенных радикальных изменений или выгоднее будет реорганизовать существующие виды деятельности?
4. Темп и характер изменений. Каким должен быть темп изменений? Должны изменения происходить постепенно или радикально? Какие группы практик должны претерпевать изменения одновременно?
5. Оценка изменений организаторами процесса. Учтены ли точки зрения всех организаторов процесса изменений? Не пропустили ли эксперты важных взаимодействий? Каковы наиболее существенные источники ресурсов?
В [28] высказывается идея о том, что информацию о комплементарных практиках и их взаимосвязях было бы весьма полезно объединить с описанием архитектуры предприятия, но делается вывод о невозможности такого описания ввиду ограниченности размеров матрицы. Несмотря на всю простоту и эффективность подхода, заложенного в матрице изменений, его применение для планирования изменений в архитектуре предприятия осложняется большим объемом данных. Как показывает практика применения матрицы, максимальная размерность, позволяющая работать с ней непосредственно, составляет 10х10 (около десятка существующих практик и столько же внедряемых). При большем количестве практик визуально-интуитивное использование этого инструмента становится невозможным.
Принципы применения матрицы изменений 2.2.
визуально-интуитивным инструментом, однако строгая методика его использования в настоящее время отсутствует. Создатели этого инструмента описывают работу с ним в виде набора рекомендаций.
Для планирования последовательности изменений при помощи матрицы изменений приводятся следующие рекомендации [66], [52]:
комплементарны базовым практикам. При этом следует избегать сценариев, когда внедряемая практика усиливает базовые практики настолько, что их удаление становится сложнее.
2. Легче всего ликвидируются практики, конкурирующие с другими базовыми практиками. Есть опасность: если удалить такие практики, то это может сделать базовую систему еще более стабильной и сопротивляющейся изменениям. Альтернатива: в взаимодействуют с другими практиками.
3. С практиками, поддерживающими большое число других практик, необходимо обращаться очень осторожно. Компания может внедрить такую практику, чтобы закрепить несколько новых практик, или удалить ее, чтобы разблокировать несколько старых.
4. Чем крупнее блоки взаимно комплементарных практик, тем сложнее их заменить. Самые сложные случаи предполагают внедрение целевых практик, которые конкурируют с наибольшим числом базовых практик.
5. Крупные блоки целевых практик нельзя внедрить, не удалив предварительно конкурирующие им базовые практики. Одна из стратегий – демонтировать эти конкурентные практики заранее.
Альтернатива – заложить фундамент из комплементарных целевых практик до начала планируемых изменений.
изменения не могут быть прерваны до того, как будет заменен весь блок.
Эти рекомендации достаточно легко могут быть использованы при малых размерах матрицы. Однако проекты архитектуры предприятия характеризуются большим числом изменений. Матрица изменений, построенная из архитектурных блоков, может достигать размерности в несколько десятков практик, что делает невозможным ее визуально-интуитивное использование.
Следует также отметить, что модель матрицы изменений является статической и приведенные рекомендации можно применить только для начального и конечного (целевого) состояния системы промежуточные состояния ввиду большого количества возможных вариантов последовательности изменений невозможно оценить визуально даже при небольшой размерности матрицы.
Таким образом, для эффективного использования матрицы изменений в целях создания архитектурной дорожной карты предприятия необходима разработка формальных методов.
последовательности действий по ее применению. Рекомендации создателей матрицы изменений представляют собой не методику, а набор возможных сценариев использования данного инструмента, которые нужно научиться идентифицировать и применять. При этом на практике возможно появление новых сценариев, не учтенных в рекомендациях. Задача построения алгоритма по приведенным рекомендациям усложняется множеством нечетких критериев, таких как «крупный блок», «наихудшие сочетания», «более стабильна» и т.п.
С другой стороны, легко заметить, что все рекомендации по выстраиванию порядка преобразований опираются на понятие легкости или трудности отдельных изменений («легче внедряются», «легче ликвидируются» и т.п.). «Легкость» изменения зависит от взаимодействий внедряемой или исключаемой практики и практик «текущей» системы (системы практик, полученной из базовой выполнением всех изменений, предшествующих текущему (оцениваемому) изменению). Внедрение отдельной практики происходит тем легче, чем больше текущая система содержит практик, комплементарных внедряемой практике, и чем меньше она содержит практик, конкурирующих с внедряемой практикой. И наоборот, исключение отдельной практики происходит тем легче, чем меньше в текущей системе комплементарных практик и чем больше конкурирующих.
Таким образом, может быть поставлена задача оптимизации последовательности изменений, в которой бы использовался показатель «легкости» изменений в качестве критерия оптимальности.
При этом «легкость» отдельного изменения может быть вычислена:
для внедрения новой практики – как сумма значений взаимодействий (+1 или -1) внедряемой практики и практик текущей системы;
для исключения существующей практики – как сумма значений взаимодействий исключаемой практики и практик текущей системы, взятая с противоположным знаком.
В статье [66] приводится еще одна рекомендация для формирования последовательности изменений – на основе расчета «чистой добавленной ценности» (Net Value Added). Эквивалентом добавленной ценности в матрице изменений выступает показатель важности практик.
Расчет чистой добавленной ценности позволяет выявить, какое из нововведений добавит предприятию наибольшую ценность.
примерную оценку чистой ценности как результата замены практик.
Если практика не имеет ответной пары, считается, что ценность ответной пары равна 0.
Для визуализации чистой добавленной ценности в [66] предлагается отсортировать изменения в виде так называемого «торнадо-графика» (рис. 8). При этом пары практик, имеющих наибольшую ценность, отображаются в верхней части графика.
Например, для пары практик «Узкие должностные обязанности – Большая ответственность» чистая добавленная ценность имеет значение 2 - (-2) = 4.
Большие запасы незавершенной и изменения наиболее важны, позволяет расставить приоритеты.
Однако если стремиться провести изменения в первую очередь на изменения исключительно по критерию наибольшей ценности, не комплементарных практик [66].
изменений, могут использоваться для формирования второго критерия оптимальности последовательности преобразований (соответствия приоритетам менеджмента предприятия).
Таким образом, на основе анализа подходов, применяемых при визуально-интуитивном использовании матрицы изменений, сформулированы содержательные положения, которые далее будут использованы для формальной постановки задачи оптимизации архитектурной дорожной карты.
Формирование матрицы изменений на основе 2.3.
архитектурных блоков TOGAF Прямое следствие из теории комплементарных взаимодействий применительно к информационным технологиям состоит в том, что эффективность инвестиций в ИТ обусловлена не только самими инвестициями в ИТ, но и изменениями в комплементарных практиках, которые происходят (или не происходят) вместе с ИТ-проектом [28].
Эту гипотезу подтверждают в своих исследованиях Э.Бринйолфсон [63] и другие авторы.
Таким образом, для обеспечения эффективного развития информационных технологий на предприятии недостаточно сформировать хорошую целевую архитектуру предприятия, перспективные возможности. Ключевым условием успешного применения архитектуры предприятия является обеспечение последовательных изменений (выполнение серии проектов) с учетом комплементарных взаимодействий (взаимного дополнения и взаимного ослабления) отдельных практик.
Матрица изменений, предложенная Э.Бринйолфссоном, организационная практика – это определенный способ решения применения матрицы изменений показывают, что в качестве организационных практик в матрицу также могут включаться цели, производства, имеющиеся технологии и т.д. [28], [45], [66].
архитектурного блока, используемого в методологии TOGAF, и введенного нами в параграфе 0. Напомним, что архитектурный блок соответствует отдельному аспекту архитектуры предприятия и отражает набор функциональности, необходимой для удовлетворения потребностей бизнеса в масштабе организации в целом [103], [105].
Рассмотрим далее, каким образом можно сформировать матрицу изменений на основе данных, получаемых на фазе E TOGAF ADM.
Для этого вначале более детально опишем процесс построения матрицы изменений.
предполагает выполнение четырех шагов:
Шаг 1. Идентификация критических практик.
Шаг 2. Идентификация взаимодействий в системе.
Шаг 3. Идентификация переходных взаимодействий.
Шаг 4. Опрос заинтересованных сторон.
Шаг 1. Идентификация критических практик.
При заполнении матрицы изменений вначале должны быть определены практики, характеризующие текущее состояние предприятия (существующие практики) и его желаемое состояние (внедряемые практики).
Для формирования матрицы изменений на основе данных TOGAF в качестве практик используются архитектурные блоки из «Консолидированной матрицы различий, решений и зависимостей»
(табл. 1), графа «Различия (архитектурные блоки)». Архитектурные блоки базовой архитектуры предприятия при этом включаются в горизонтальную таблицу матрицы изменений (существующая система практик предприятия). Архитектурные блоки целевой архитектуры предприятия включаются в вертикальную таблицу матрицы изменений (целевая система практик предприятия).
Кроме того, в матрицу изменений включаются практики, соответствующие факторам из «Матрицы оценки факторов внедрения» (табл. 2). Факторы внедрения, как правило, носят постоянный характер, поэтому они должны присутствовать в обеих таблицах матрицы изменений.
Рисунок 9. Горизонтальная и вертикальная матрицы Шаг 2. Идентификация взаимодействий в системе.
На данном шаге строится горизонтальная треугольная матрица для идентификации взаимодействий между существующими практиками и вертикальная треугольная матрица для идентификации взаимодействий между внедряемыми практиками (рис. 9). Знак соответствующие практики комплементарны (то есть взаимно усиливают друг друга), а знак «минус» (–) – что практики являются конкурирующими (то есть взаимно ослабляют друг друга).
Для выявления этих взаимодействий и заполнения треугольных матриц используется информация из «Консолидированной матрицы различий, решений и зависимостей» (графа «Зависимости») и «Матрицы оценки факторов внедрения» (графа «Выводы (влияние на план миграции)»).
Шаг 3. Идентификация переходных взаимодействий.
На шаге 3 создается матрица перехода – прямоугольная матрица, комбинирующая горизонтальную и вертикальную таблицы (рис. 10).
возникающие при движении от базовой системы практик к целевой, что помогает оценить степень сложности данного перехода. При этом обозначаются аналогично шагу 2.
Рисунок 10. Формирование матрицы перехода Для выявления взаимодействий между базовыми и целевыми практиками на основе результатов TOGAF так же, как и на шаге 2, используются «Консолидированная матрица различий, решений и зависимостей» и «Матрица оценки факторов внедрения».
Шаг 4. Опрос заинтересованных сторон.
Выполняется оценка важности существующих и внедряемых практик организаторами процесса изменений в компании. Каждая практика оценивается экспертами, составляющими матрицу, по шкале Ликерта:
+2 – практика крайне важна;
+1 – практика важна;
0 – практикой можно пренебречь;
-1 – практика создает некоторые трудности в эффективной организации бизнеса, ее желательно заменить / трансформировать;
-2 – практика создает существенные трудности в организации успешного бизнеса, ее необходимо заменить / трансформировать.
Согласно TOGAF ADM по каждому пакету работ на фазе F выполняется присвоение показателей бизнес-ценности. Однако для формирования матрицы изменений требуется аналогичная оценка именно для архитектурных блоков на фазе E. Следовательно, в дополнение к описанным шагам фазы E должна быть выполнена оценка архитектурных блоков по приведенной выше шкале.
Следует отметить недостаточность матрицы изменений, как модели, формализующей данные, используемые для выстраивания последовательности изменений при формировании архитектурной дорожной карты, по следующим причинам:
отсутствие информации о явной замене некоторых практик (практика «А» базовой системы практик заменяется на практику «Б» целевой системы практик) – соответствующие изменения должны выполняться одновременно;
отсутствие информации о заранее определенном порядке для отдельных практик (например, практика «А» должна последовательность, обусловленная созданием и обработкой базовую, так и в целевую систему практик только для архитектурными блоками;
высокая трудоемкость описания взаимодействий практик и их визуального восприятия в матрицах изменений большой Таким образом, нами описан способ формирования матрицы изменений для формализации взаимодействия архитектурных блоков в целях дальнейшего использования этой модели для обоснованного формирования архитектурной дорожной карты TOGAF. При этом прогнозируемая размерность матрицы не позволит применять ее визуально-интуитивно, поэтому дальнейшее решение данной задачи целесообразно строить на основе математической модели.
В то же время, выявлены недостатки матрицы изменений, ограничивающие создание формальных методов работы с ней.
Данные недостатки позволяют сделать вывод о необходимости расширения модели «Матрица изменений» при ее использовании в дополнение к методу TOGAF ADM.
Далее при ссылках на структуру матрицы изменений во избежание разночтений будем пользоваться термином «практика»
[45].
Построение математической модели взаимодействия 2.4.
архитектурных блоков Оригинальная матрица изменений содержит два множества практик (рис. 12):
существующие практики – принадлежат базовой системе практик и задаются горизонтальной таблицей, внедряемые практики – принадлежат целевой системе практик и задаются вертикальной таблицей.
заменяются на внедряемые при переходе от базовой системы практик к целевой.
При описании способа формирования матрицы на основе данных TOGAF (параграф 2.1) обоснована необходимость введения в нее практик, которые не изменяются при переходе от базовой системы практик к целевой. Поэтому для определенности далее будем выделять практики:
исключаемые – практики базовой системы практик, которые подлежат удалению (исключению) при переходе к целевой подлежащие внедрению (новые для предприятия практики);
постоянные – практики, которые не изменяются при переходе от базовой системы к целевой, и входят в обе Вначале построим математическую модель оригинальной матрицы изменений, описанной в [66].
– количество практик базовой системы, и – множество внедряемых практик, где m – количество практик целевой системы.
практик, входящих в матрицу.
Шкалу важности практик обозначим как множество, тогда показатель важности каждой практики можно определить как функцию Определим шкалу взаимосвязи практик как множество (значение «–1» соответствует взаимному ослаблению практик (в матрице – «–»), значение «1» – взаимному усилению практик (в матрице – «+»), значение «0» – независимости практик).
Взаимосвязи практик зададим при помощи функции изменений как взвешенный граф (рис. 13) вида Рисунок 13. Представление матрицы изменений в виде графа базовую систему практик, а подграф – целевую:
При описании способа формирования матрицы изменений на основе данных TOGAF (параграф 2.1) были перечислены недостатки этой модели, которые, в частности, не позволяют представить в ней следующую информацию:
обозначение постоянных (неизменяемых) архитектурных явная замена архитектурных блоков базовой архитектуры на блоки целевой архитектуры;
заранее определенный порядок внедрения или исключения архитектурных блоков.
Введем эту информацию, расширив описанную математическую блоков». Практиками в этой модели будут являться архитектурные блоки, а также факторы, влияющие на выполнение архитектурных преобразований.
Для обозначения постоянных (неизменяемых) архитектурных блоков и факторов внешней и внутренней среды предприятия введем постоянных практик. Соответственно переопределим множество всех практик матрицы :
Тогда размерность графа (2.3) будет увеличена на :
Заметим, что постоянные практики вводятся в модель только для оценки их влияния на базовую и целевую системы практик. Сами Кроме того, по той же причине отсутствует необходимость оценки При этом макет соответствующей матрицы изменений будет иметь вид, представленный на рис. 14.
Рисунок 14. Макет расширенной матрицы изменений архитектурных блоков, изображен на рис. 15.
Рисунок 15. Граф модели взаимодействия архитектурных блоков системы практик (базовую и целевую архитектуры предприятия), определяются для модели взаимодействия архитектурных блоков следующим образом:
Явную замену практик зададим при помощи множества упорядоченных пар Порядок выполнения изменений, существующий для некоторых практик, введем также посредством множества упорядоченных пар:
возможны другие изменения).
Итак, математическую модель взаимодействия архитектурных блоков можно представить в виде совокупности N вида:
базовой системы практик (2.5), – граф целевой системы практик (2.6), значений взаимосвязи практик (2.2), – множество упорядоченных пар явной замены практик (2.7), – множество упорядоченных пар порядка изменений, заранее заданного для некоторых пар практик (2.8).
Практиками в данной модели являются архитектурные блоки, а преобразований.
Построение модели реструктуризации архитектуры 2.5.
взаимодействия архитектурных блоков может быть поставлена задача оптимизации последовательности изменений, как задача оптимальной трансформации графа в граф через цепочку промежуточных принадлежащих множеству, и включения вершин, принадлежащих множеству. Эта трансформация, отражающая последовательность изменений, будет соответствовать архитектурной дорожной карте.
В целях постановки подобной экстремальной задачи опишем далее формальную модель реструктуризации архитектуры предприятия. При помощи этой модели имитируется процесс перехода от текущего состояния архитектуры предприятия к ее архитектуры предприятия должны моделироваться и оцениваться при помощи модели взаимодействия архитектурных блоков.
трансформации графов в [40], введем следующие определения:
При элементарном преобразовании вместе с вершинами, инцидентные одновременно включаемой вершине и вершинам графа преобразований последовательность элементарных преобразований представлен на рис. 16.
математической моделью взаимодействия архитектурных блоков (параграф 2.4).
выполнение одной и той же бизнес- или ИТ-функции двумя разными способами, соответствующими текущему и целевому состоянию непосредственно за исключением старой). Будем считать это условие достаточным для выполнения пары изменений в рамках одного Для выполнения условия частичного порядка изменений, заданного множеством упорядоченных пар, введем следующее Задача, решаемая при использовании матрицы изменений для выстраивания порядка изменений с учетом взаимодействия практик, содержательно описана нами при изложении принципов применения этого инструмента (параграф 2.2). Эта задача состоит в том, чтобы выбрать последовательность исключения практик базовой системы и внедрения практик целевой системы, обеспечив «легкость»
изменений. Кроме того, в параграфе 2.2 был также описан критерий «чистой добавленной ценности», который позволяет задать приоритеты для изменений. Чистая добавленная ценность для пары практик «исключаемая-внедряемая» вычисляется как разница показателей важности внедряемой и исключаемой практик. Пары практик, имеющих больший показатель чистой добавленной ценности, имеют больший приоритет и должны участвовать в изменениях раньше.
соответствующие количественные оценки.
Введем сначала функцию «легкости изменения» (или просто «легкости») для элементарного преобразования.
Согласно определению 1, элементарному преобразованию соответствует либо внедрение новой практики, либо исключение существующей. Чем больше комплементарных и чем меньше конкурирующих взаимодействий между внедряемой практикой и соответствующие изменения. При исключении практики – наоборот – комплементарные взаимодействия будут мешать изменению существующего порядка вещей, а конкурирующие – содействовать изменениям (параграф 2.2). Таким образом, легкость отдельного изменения в матрице изменений определяется:
для внедрения новой практики – как сумма значений взаимодействий (+1 или -1) внедряемой практики и практик текущей системы практик;
взаимодействий исключаемой практики и практик текущей системы практик, взятая с противоположным знаком.
вычисляется относительно текущего состояния системы практик, представленного графом.
внедрении новой практики, будет соответствовать выражение:
Легкости исключения базовой практики – то же выражение с противоположным знаком:
Следовательно, можно записать функцию легкости преобразования :
Определим теперь показатели, которые будем использовать для оценки архитектурной дорожной карты в целом, как показатели соответствующей ей траектории.
Исходя из содержательных соображений, наиболее очевидным интегральным критерием оценки траекторий является суммарная легкость ее элементарных преобразований:
Такой показатель, хотя и не учитывает возможных провалов и скачков легкости отдельных преобразований, но может быть интерпретирован как общая легкость перехода от базовой системы практик к целевой, которую следует максимизировать за счет выбора соответствующей траектории. Однако при проведении ряда экспериментов с матрицей изменений, описанной в статье [66], было установлено, что показатель имеет одно и то же значение для всех построенных траекторий (-4).
Данный факт позволяет выдвинуть гипотезу о том, что суммарная легкость элементарных преобразований для любой траектории является свойством модели и не зависит от выбранной траектории.
Проверим эту гипотезу путем доказательства теоремы, а также определим способ вычисления, не требующий построения промежуточных графов.
Теорема о суммарной легкости преобразований. Суммарная легкость элементарных преобразований любой траектории одной и той же модели взаимодействия архитектурных блоков есть величина постоянная (то есть не зависит от порядка преобразований). Она равна сумме взаимодействий целевой системы практик за вычетом суммы взаимодействий базовой системы практик и не зависит от взаимодействий между внедряемыми и исключаемыми практиками:
Приведем доказательство для простейшего случая.
Пусть модель взаимодействия архитектурных блоков задана полным графом (рис. 17), в котором выделены подграфы базовой и целевой систем практик и.
Рисунок 17. Граф матрицы изменений для простейшего случая Пусть дана траектория преобразований:
легкости (2.13): либо в траектории). Это вхождение будет соответствовать либо внедрению, либо в ( ), причем со знаком «минус».
возможен только один вариант порядка преобразований, поскольку соответствии с определением промежуточного графа (определение 2).
ровно по одному разу со знаком «минус» в выражения (2.13) для преобразований:
«плюс», а в соответствующих текущих системах практик будут присутствовать, ни в ( ), поскольку ответные пары практик в текущих системах будут отсутствовать.
Таким образом, определив слагаемые, входящие во все преобразований, мы можем получить обобщенное выражение для (2.14). Любая траектория будет состоять из элементарных что легкость отдельного преобразования зависит от значения i (места в траектории), поскольку состояние текущей системы практик определяется преобразованиями, выполненными до i-го. Однако быть также представлена в виде суммы значений взаимодействия пар практик.
«