Оптимальный путь к корпоративным архитектурам (Часть 2)
в рубрике ALM, Другое, Методологии, Технологии
Роджер Сешнс (Roger Sessions)
Это продолжение статьи Роджера Сешнса “Оптимальный путь к корпоративным архитектурам”. Рекомендуем прочитать первую часть
Сложность
Чтобы определить причины неудач при использовании различных методик создания корпоративных архитектур, нужно понять, что общего между всеми неудачными попытками создания корпоративных архитектур. Что же общего у столь разных систем — у системы управления финансами Налогового управления, системы управления бизнесом Министерства обороны, системы управления действиями в чрезвычайных ситуациях Министерства национальной безопасности, системы управления ФБР Virtual Case File, системы управления бизнесом компании Макдоналдс, системы закупок компании Форд и системы управления каналом поставок компании KMart?
У всех этих систем только одна общая характеристика — сложность. Все эти системы обладают высокой сложностью. Я считаю, что основным недостатком архитектур FEAF и TOGAF и архитектуры Захмана является невозможность управления сложностью систем.
К сожалению, сложность — это не сиюминутная помеха. Можно с уверенностью сделать три предположения о будущем ИТ-отрасли:
В недавней статье, опубликованной в InformIT, Ричард Мур (Richard Murch) охарактеризовал положение дел следующим образом:
“Ничего не предпринимать, чтобы помешать дальнейшему повышению сложности ИТ-инфраструктур и архитектур — неприемлемо и безответственно. Если мы просто бросим на решение этой проблемы новых квалифицированных программистов и других специалистов, настанет хаос … Пока пользователи и поставщики ИТ-систем решают проблему сложности похожим образом, подобные проблемы будут возникать снова и снова, мешая работе отрасли”. [Mur]
Моделирование сложности
Чтобы управлять сложностью, необходимо вначале понять ее особенности. Научившись моделировать сложность, мы сделаем большой шаг к ее пониманию.
Лучшая модель сложности, которая мне известна, — это игральный кубик. Она интуитивно понятна, наглядна, предсказуема и математически обоснована. Я изложил основные положения этой модели в виде закона сложности Сешнса: сложность системы является функцией числа возможных состояний системы
Для понимания этого закона воспользуемся кубиком. Я буду сравнивать сложность двух случайных систем: системы А и системы Б, показанных на рис. 1. Система А состоит из одной двусторонней фигуры (т. е. “монеты”). Система Б состоит из одного кубика с шестью гранями (стандартный игральный кубик).
Рис. 1. Система А и система Б
Система А имеет два возможных состояния: орел и решка. Система Б имеет шесть возможных состояний: 1, 2, 3, 4, 5 и 6. В соответствии с законом сложности Сешнса система Б в 6/2 раз (т. е. в 3 раза) сложнее системы А. Даже если не вникать в математическое обоснование, это интуитивно понятно.
В общем случае число состояний системы, состоящей из D кубиков, каждый из которых имеет S сторон, равно SD. С помощью этой формулы мы можем определять сложность других систем.
Теперь давайте сравним системы Б и В. Система Б, как и ранее, состоит из одного кубика с шестью гранями, а система В — из трех кубиков с шестью гранями, как показано на рис. 2.
Рис. 2. Система Б и система В
Число состояний системы Б по-прежнему равно 61 (или 6), а число состояний системы В равно 63 (т. е. 216). В соответствии с законом сложности Сешнса система В в 216/6 раз (т. е. в 36 раз) сложнее системы Б.
Если вы захотите предсказать результат броска кубиков в системе В, у вас будет 1 шанс из 216 угадать правильную комбинацию. Если вы захотите предсказать результат броска кубиков в системе Б, у вас будет 1 шанс из 6 угадать правильную комбинацию. Если вы сделаете серию предсказаний относительно обеих систем, в среднем вы сможете правильно предсказать состояние системы Б в 36 раз чаще, чем системы В. Поскольку система Б менее сложная, чем система В, она легче поддается прогнозированию
Декомпозиция
Используя эту базовую модель сложности, мы можем найти методы, позволяющие усовершенствовать организацию сложных систем.
Сравним две системы — систему В и систему Г, — каждая из которых состоит из трех шестигранных кубиков. В системе В кубики, как и ранее, находятся вместе, а в системе Г разделены на три подсистемы. Эти системы показаны на рис. 3.
Рис. 3. Система В и система Г
Предположим, мы можем использовать каждую из трех подсистем независимо (т. е. каждая подсистема будет представлять собой систему, подобную системе Б).
Мы знаем, что сложность системы В будет равна 216. Совокупная сложность системы Г определяется как сумма сложностей подсистем 1, 2 и 3. В соответствии с правилом SD, сложность каждой подсистемы будет равна 61, или 6. Таким образом, сложность системы Г будет равна 6+6+6, или 18.
Если вас это не убеждает, представьте себе, что вам надо проверить правильность работы систем В и Г. При проверке системы В вам придется проверить правильность 216 различных состояний, а при проверке системы Г — только 6 различных состояний при проверке работы первой подсистемы, еще 6 — при проверке работы второй подсистемы и еще 6 — при проверке работы третьей.
Таким образом, сложность системы, состоящей из P подсистем, каждая из которых имеет сложность C, составляет C*P. Если каждая подсистема будет состоять только из одного кубика, эта формула примет вид S1*D, что снижает сложность до S*D.
Теперь давайте обобщим полученный результат на все системы, прошедшие и не прошедшие декомпозицию. Чтобы упростить задачу, предположим, что подсистемы всегда состоят из одного кубика (как в случае с системой Г). При этом сложность системы, не проходившей декомпозицию (например, системы В) всегда равна SD, а сложность системы, прошедшей декомпозицию (например, системы Г), всегда равна S*D.
Таким образом, вопрос можно свести к следующему: как соотносятся между собой формулы (S*D) и (SD)? В таблице 1 приведены значения, вычисленные по формулам S*D (система с декомпозицией) и SD (система без декомпозиции) для различных значений величин S и D.
Таблица 1. Сложность систем с декомпозицией и без декомпозиции
Таблица 1 наглядно показывает, насколько система из 9 кубиков, не разбитая на подсистемы, сложнее, чем система, содержащая 9 кубиков, но прошедшая декомпозицию. Отношение сложностей этих систем составляет 10 077 696 к 52 (для неспециалистов: очень-очень(!) много).
Вывод, который можно сделать на основании таблицы 1, понятен: чем выше совокупная сложность системы, тем сильнее ее можно уменьшить с помощью декомпозиции.
Итак, декомпозиция — это первый метод борьбы со сложностью.
Итерации
Уменьшив сложность системы с помощью декомпозиции, мы сталкиваемся еще с одной проблемой. Как проанализировать оставшуюся сложность? Существует два подхода: итерационный (слева направо) и рекурсивный (сверху вниз). Чтобы понять отличия этих походов, давайте еще раз рассмотрим модель сложности системы из кубиков, прошедшей декомпозицию (см. рис. 4).
Рис. 4. Система из кубиков после декомпозиции
При использовании итерационного подхода мы анализируем каждую подсистему по отдельности. Например, сначала проанализируем подсистему 1, затем подсистему 2 и так далее.
Итерационный подход основан на анализе горизонтальных уровней каждой подсистемы. Например, сначала мы должны проанализировать ситуацию, в которой на всех кубиках выпало значение 1, затем — ситуацию, в которой на первом кубике выпала единица, а на остальных — двойки, и так далее, пока не переберем все возможные состояния для всех подсистем.
Какой метод лучше? Итерационный или рекурсивный?
Для ответа на этот вопрос вернемся в 1950 год, к любознательному полковнику военно-воздушных сил по имени Джон Бойд (John Boyd) [Boy]. Бойда не интересовали вопросы создания сложных ИТ-систем. Скорее всего, он даже никогда не слышал ни про корпоративную архитектуру, ни вообще про ИТ-системы. Он хотел понять, как побеждать в воздушных дуэлях.
Воздушная дуэль — это воздушный бой между двумя пилотами истребителей, каждый из которых старается попасть в соперника раньше, чем соперник попадет в него. Теперь вы понимаете, почему полковник ВВС хотел научиться побеждать в таких боях.
Управление истребителем в воздушном бою — сложнейшая задача. Пилот должен анализировать информацию из множества источников. А в это время противник пытается его сбить. Чтобы понять, насколько сложную задачу должны были решать пилоты Бойда, посмотрите на рис. 5, на котором показана кабина истребителя
Рис. 5. Кабина истребителя
Бойда интересовали не любые воздушные бои, а воздушные бои между самолетами МИГ-15С и F-86s. Бывший пилот и опытный авиаконструктор Бойд очень хорошо знал особенности этих самолетов. Он знал, что МИГ-15 был более совершенным самолетом, чем F-86: он быстрее набирал высоту, быстрее поворачивал и имел большую дальность обзора.
Однако существовала одна проблема. Хотя Бойд и большинство других авиаконструкторов считали МИГ-15 великолепным самолетом, пилоты предпочитали F-86. Причина была очень простой: в одиночных воздушных дуэлях F-86 выигрывал у МИГ-15 девять поединков из десяти.
Эта ситуация заинтересовала Бойда. Почему отличный самолет полностью проигрывает самолету с худшими характеристиками?
Чтобы разрешить эту проблему, Бойду надо было понять, каким образом пилоты действуют в воздушном бою. У Бойда было существенное преимущество — в прошлом он был не только пилотом, но и одним из самых умелых мастеров воздушных дуэлей, и имел опыт ведения воздушных боев.
Давайте представим себе пилота, участвующего в воздушной дуэли. Назовем его Питом. Бойд предположил, что для Пита воздушный бой состоит из четырех этапов. На первом этапе Пит наблюдает за окружающей обстановкой, включая самолет противника. На втором этапе Пит ориентируется в соответствии с этой ситуацией. На третьем этапе Пит планирует дальнейшие действия, а на четвертом действует.
Таким образом, Пит сначала наблюдает, затем ориентируется, составляет план и действует. Бойд назвал эту последовательность OOPA (observe, orient, plan, act).
Те, кто читал работы Бойда, могут заметить, что Бойд называл этот цикла OODA — observe, orient, deploy, act (наблюдение, ориентация, развертывание и действие, или НОРД). Однако в этой статье термин “развертывание” заменен термином “планирование”. Это сделано по двум причинам. Во-первых, чтобы не создавать путаницы для читателей, знающих, что аббревиатура OODA расшифровывается как “объектно-ориентированное проектирование и анализ”. Во-вторых, читая работы Бойда, я пришел к выводу, что используемый в ИТ-отрасли термин “план” по значению близок к тому, что Бойд называл “развертыванием”.
Однако, и это очень важно, Питу приходится выполнять эту последовательность действий снова и снова. То есть Пит все время циклически проходит этапы OOPA. И, разумеется, то же самое делает его противник. Кто же победит? Пит? Или анти-Пит? Мы знаем, что если Пит летает на F-86, он, вероятно, победит. Но почему?
Кажется, что анти-Пит, управляющий МИГ-15, сможет выполнить этапы цикла OOPA лучше, чем Пит. Поскольку он дальше видит и может сделать более точные наблюдения, а поскольку он быстрее поворачивает и набирает высоту, он должен и быстрее реагировать. Однако анти-Пит проигрывает, а Пит побеждает!
Бойд решил, что основным фактором, от которого зависит победа в воздушной дуэли, является не способность точнее наблюдать и лучше ориентироваться, планировать и действовать, а возможность выполнять эти этапы быстрее. Другими словами, насколько быстро пилот может выполнить тот или иной этап. Бойд предположил, что скорость выполнения важнее качества.
После этого Бойд задал вопрос: «Почему пилоты F-86 выполняют эти этапы быстрее?» По мнению Бойда, причина крылась в факторе, которому никто не уделил особого внимания — на F-86 устанавливался штурвал с гидравлическим усилителем, а на МИГ-15 — ручной.
В результате перемещение штурвала требовало от пилота МИГ-15 несколько больших усилий, чем от пилота F-86. Поэтому, хотя после движения штурвалом МИГ-15 мог быстрее поворачивать и набирать высоту, само перемещение штурвала давалось пилоту МИГ-15 труднее.
При каждом повторении цикла пилот МИГ-15 уставал немного больше, чем пилот F-86. И чем сильнее он уставал, тем больше времени тратил на выполнения цикла OOPA. Таким образом, пилот МИГ-15 проигрывал не потому, что противник имел перевес, а потому, что отставал в выполнении цикла OOPA.
Я изложу открытие Бойда в виде закона повторений Бойда: в сложных условиях быстрые повторения почти всегда обеспечивают лучшие результаты, чем углубленный анализ.
Итерации с декомпозицией
Итак, теперь мы знаем два принципа, позволяющих лучше управлять сложностью корпоративных архитектур. Изучая кубики, мы увидели, что декомпозиция — один из основных способов уменьшения сложности, а из работ Бойда, посвященных воздушным боям, узнали, что лучший способ анализа подсистем сложных систем — последовательные итерации, при выполнении которых необходимо уделять основное внимание скорости, а не полноте.
Теперь давайте посмотрим, как можно применить эти принципы к
сложным корпоративным архитектурам. Представьте себе крупномасштабную систему управления бизнесом (например, такую, на безуспешное создание которой компания Макдоналдс потратила 170 млн долларов). Я буду называть эту систему СКСУБ (сложная крупномасштабная система управления бизнесом). Предположим, что СКСУБ должна предоставлять следующие возможности:
Как выполнить декомпозицию такой системы? Приведенный выше перечень уже содержит подсказку. Не надо создавать единый гигантский проект СКСУБ. Необходимо создать архитектуру управления кадрами, архитектуру ведения платежных ведомостей — и так далее. Другими словами, не пытайтесь разработать единую, сложную, крупномасштабную систему — создайте несколько небольших и простых систем. Спроектируйте одну систему, разработайте ее и переходите к следующей. Декомпозиция снижает общую сложность. Итерации повышают вероятность успеха.
Можно предположить, что в упомянутых выше неудачных попытках создания корпоративных архитектур (таких как разрабатываемая ФБР система управления виртуальными делами и создаваемая Макдоналдс система управления бизнесом) использовались стандартные методики разработки корпоративных архитектур (такие как FEAF , TOGAF и модель Захмана). Все этим методики не являются итерационными. Поэтому неудивительно, что эти попытки потерпели неудачу. Также неудивительно, что на эти проекты были потрачены очень большие средства.
Во всех методиках разработки корпоративных архитектур сказано, что процесс создания корпоративной архитектуры должен включать следующие этапы:
Традиционные методики предполагают, что каждый этап выполняется один раз и полностью завершается до перехода к следующему этапу. Эта ситуация проиллюстрирована на рис. 6.
Рис. 6. Подход на основе создания единого проекта
Как видно по рисунку 6, создание архитектуры в соответствии с традиционной методикой начинается с углубленного проектирования бизнес-архитектуры конечной системы (например, воображаемой системы СКСУБ, о которой говорилось выше). После этого создается техническая архитектура, а затем выполняются реализация, тестирование, отладка и развертывание. Обратите внимание, что пока полностью не завершится этап развертывания, проект не имеет никакой коммерческой ценности.
Данный пример позволяет также понять, что должны были сделать эти организации. Они должны были использовать итерационный подход с декомпозицией.
Итерационный подход с декомпозицией в корне отличается от традиционного подхода. Действия при использовании этого подхода показаны на рис. 7. Обратите внимание, что приведенный выше порядок выполнения этапов не изменился, однако сейчас мы выполняем каждый этап с разбиением на подсистемы.
Рис. 7. Итерации с декомпозицией
Результатом такого подхода является постоянное расширение функциональности. Мы не начинаем работу над следующей подсистемой, пока не завершена работа над предыдущей. Хотя одновременное выполнение нескольких проектов — достаточно распространенная ситуация для крупных организаций со сложной структурой, число таких проектов необходимо свести к минимуму, поскольку их одновременное выполнение требует более эффективной координации.
Анонс:
26 марта в Москве пройдет первая Enterprise Developers Conference.
Если вы архитектор предприятия или разработчик в крупной компании, не пропустите это событие.
Прокомментировать
Вы должны быть авторизованы для комментирования.
