Оптимальный путь к корпоративным архитектурам. Создание распределенных приложений.

Роджер Сешнс (Roger Sessions), Апрель 2006г.

http://msdn.microsoft.com/ru-ru/library/ee895290.aspx

Роджер Сешнс представляет рекомендации по созданию эффективной корпоративной архитектуры путем применения итераций с декомпозицией — процесса, основанного на практических следствиях теории вероятностей и стратегии ведения военных действий.

Введение

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

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

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

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

Как же управлять сложностью? Ответ на этот вопрос лежит там, где вы его вряд ли ожидали найти — в области стратегии боевых действий. Вы увидите, каким образом опыт пилотов истребителей, которые стремились победить в воздушных боях 50 лет назад, может помочь в создании современных сложных корпоративных инфраструктур.

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

Определение корпоративной архитектуры

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

Университет Карнеги — Меллон (в котором работают признанные авторитеты в этой области) предлагает следующее определение.

«Корпоративная архитектура — это средство описания бизнес-структур и соединяющих их процессов». [CMU]

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

Википедия предлагает более полное определение.

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

Определение из Википедии лучше отражает сложность многих современных методологий создания корпоративной архитектуры. Еще более полное определение дает Управление по информационным технологиям правительства США.

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

Вы уже начали понимать, почему корпоративные архитектуры могут требовать значительных затрат? При создании корпоративной архитектуры необходимо задокументировать огромные объемы информации.

Дороговизна создания корпоративной архитектуры объясняется следующими факторами:

Длительные сроки, необходимые для всестороннего анализа
Вовлечение в процесс большого числа высокопоставленных сотрудников организации
Привлечение большого числа дорогостоящих консультантов, необходимых, чтобы ориентироваться в сложных методиках

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

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

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

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

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

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

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

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

Сходство корпоративной архитектуры с планом города впервые было отмечено Армором в 1999 году [Arm], и частично сохраняется и для современных организаций с высоким уровнем сложности.

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

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

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

История корпоративных архитектур

Принято считать, что направление корпоративных архитектур появилось в 1987 году после публикации в IBM Systems Journal статьи Захмана «A framework for information systems architecture» («Инфраструктура для архитектуры информационных систем») [Zac]. В дальнейшем Захман переименовал инфраструктуру «информационных систем» в инфраструктуру «корпоративной архитектуры». Сегодня эта инфраструктура известна как инфраструктура Захмана.

В 1994 году Министерство обороны США представило архитектуру технического обеспечения для управления информацией (Technical Architecture Framework for Information Management, TAFIM) [TAF]. Архитектура TAFIM позиционировалась как новый стандарт корпоративной архитектуры для всех оборонных работ и прошла через ряд итераций, пока не была полностью отменена в 2000 году.

Хотя архитектура TAFIM больше не используется, некоторые ее принципы нашли применение в инфраструктуре архитектуры Open Group (TOGAF). TOGAF — это инфраструктура «с открытым кодом», контролируемая консорциумом Open Group. В настоящее время используется версия 8.1 [TOG]. По всей видимости, TOGAF — это наиболее популярная на сегодняшний день инфраструктура корпоративной архитектуры из используемых в частном секторе. Несколько реже используется модель Захмана.

В 1996 году развитие корпоративных архитектур ускорилось благодаря принятию Конгрессом США акта Клингера — Коэна, называемого также Законом о реформе управления информационными технологиями (Information Technology Management Reform Act, ITMRA). Этот закон предоставляет Административно-бюджетному управлению США (OMB) широкие права «анализа, отслеживания и оценки рисков и результатов всех крупных капиталовложений в информационные системы, совершаемых органами исполнительной власти». [Cli]

Акт Клингера — Коэна требует от всех органов исполнительной власти назначать директоров по ИТ, которые, в частности, несут ответственность за «разработку, сопровождение и упрощение внедрения ... интегрированной инфраструктуры, предназначенной для развития или сопровождения существующих ИТ-продуктов и приобретения новых ИТ-продуктов, необходимых для достижения стратегических целей соответствующего учреждения и управления информационными ресурсами». [Cli]

Хотя в акте Клингера — Коэна ничего не говорится о корпоративной архитектуре, OMB расценило этот закон как поручение создать универсальную инфраструктуру корпоративной архитектуры для правительства США в целом. Этаинфраструктураполучиланазвание FEAF (Federal Enterprise Architectural Framework) [FEA]. Сегодня OMB требует от всех органов исполнительной власти, от Министерства юстиции до Министерства национальной безопасности и Министерства сельского хозяйства, разработать корпоративную архитектуру и показать, каким образом эта архитектура соотносится с FEAF.

Таким образом, фактическим результатом принятия акта Клингера — Коэна стало то, что все работы, относящиеся к ИТ и проводимые правительственными учреждениями США или для правительственных учреждений США, должны (по крайней мере, теоретически) выполняться в рамках единой, общей корпоративной архитектуры.

Примеры внедрения в государственном секторе

Акт Клингера — Коэна не только обязывает использовать архитектуру Federal enterprise architecture (а именно так его трактуют), но и требует регулярно проводить мониторинг программ и составлять отчеты, позволяя нам увидеть масштабную корпоративную архитектуру в действии.

Фактически перед нами — практический пример использования всеобъемлющей корпоративной архитектуры (FEAF) самой крупной организацией в мире — правительством США. А поскольку на архитектуру FEAF оказали значительное влияние архитектуры TOGAF и Захмана, мы можем экстраполировать на них выводы, полученные при изучении FEAF.

Так как же Правительство США справилось с этой задачей?

По-видимому, не очень хорошо. Не было практически ни одного месяца, в который Счетная палата (GAO), независимый контролирующий орган правительства США, не направило бы крайне негативный отзыв об использовании информационных технологий хотя бы в одном учреждении. Создается впечатление, что чем важнее роль конкретного правительственного органа, тем больше вероятность значительных проблем в работе его ИТ-систем.

В ноябре 2005 года GAO обнаружило следующие проблемы в работе ИТ-систем Налогового управления США (IRS).

«Отсутствие высококачественной системы управления финансами, способной своевременно предоставлять точные данные, которые ежедневно нужны для принятия решений, остается серьезным недочетом в управлении IRS. Система управления финансами, используемая IRS в настоящее время, ... ограничивает возможности IRS реагировать на оперативные проблемы и проблемы управления финансами, которые необходимо разрешать в ходе работы национального сборщика налогов». [GAO1]

Министерство обороны также неоднократно подвергалось критике. Например, в июне 2005 года в отчете GAO было отмечено следующее.

«Значительные недочеты в управлении финансовой и коммерческой деятельностью Министерства обороны не только негативно влияют на способность предоставлять финансовые данные для аудита, но и препятствуют своевременному получению руководством министерства и Конгрессом США точной и полной информации, необходимой для принятия решений. Кроме того, отсутствие надлежащего учета при выполнении всех основных коммерческих операций Министерства обороны приводит к неоправданным ежегодным расходам, исчисляемым миллиардами долларов, в условиях роста бюджетных ограничений и оказывает отрицательное влияние на работу». [GAO2]

В играющем важнейшую роль Министерстве национальной безопасности также существует множество проблем. В августе 2004 года в отчете GAO говорилось следующее.

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

Этот перечень можно продолжать до бесконечности. ФБР долго критиковали за разбазаривание свыше 500 млн долларов, потраченных на неудачный проект по созданию системы управления делами. Федеральное агентство по управлению в чрезвычайных ситуациях потратило более 100 млн долларов на систему, которая оказалась неэффективной при устранении последствий урагана «Катрина». Критике GAO подверглись и другие правительственные органы, включая Бюро переписи населения, Федеральное авиационное управление, NASA, Министерство жилищного строительства и городского развития, Министерство здравоохранения и социальных служб, а также федеральная программа медицинской помощи престарелым и федеральная система медицинской помощи неимущим.

Однако наиболее парадоксальным, по всей видимости, является то, что одним из подразделений, которые не выполнили требования акта Клингера — Коэна, стало... Административно-бюджетное управление — орган, который должен проверять выполнение этого закона другими правительственными учреждениями!

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

Примеры внедрения в частном секторе

Хотя неудачные внедрения в частном секторе не вызывают такого же резонанса в СМИ, компании частного сектора также допускают серьезные промахи при широкомасштабном развертывании ИТ. В частности, можно вспомнить следующие неудачные попытки внедрения корпоративной архитектуры в частном секторе.

Компания Макдоналдс не смогла создать интегрированную систему управления бизнесом, которая должна была объединить все рестораны компании. Затраты: 170 млн долларов [Mac]
Компании Форд не удалось разработать интегрированную систему закупок. Затраты: 400 млн долларов [For]
Компания KMart не смогла создать современную систему управления каналом поставок. Затраты: 130 млн долларов [Kma]

В статье, появившейся недавно в «Нью-Йорк таймс», Николас Гарр (Nicholas G. Carr) делает такое заключение:

«Глядя на частный сектор, можно прийти к выводу, что неудачи с программным обеспечением являются обыденным явлением. И чем амбициознее проект, тем больше вероятность неудачи». [Car]

В статье, опубликованной недавно в IEEE Spectrum, содержится следующая мрачная оценка.

«Принимая во внимание совокупный размер инвестиций в новые корпоративные и государственные программные проекты за последние пять лет, я делаю вывод, что неудачи при реализации этих проектов будут стоить экономике США от 25 до 75 млрд долларов. Разумеется, в эти 75 млрд не включены ни проекты, превысившие бюджет, что происходит с большинством проектов, ни проекты, сроки реализации которых были нарушены, что также происходит в большинстве случаев. Кроме того, в эту сумму не включены скрытые издержки на повторное выполнение остановленного ранее проекта и устранение ошибок в системах, многократно подвергавшихся переработке. [Cha]

И в государственном, и в частном секторе мы раз за разом сталкиваемся с масштабными и дорогостоящими корпоративными архитектурами, не способными удовлетворить требования бизнеса и использовать технологические решения. С учетом вышесказанного можно прийти к выводу, что либо корпоративные архитектуры бесполезны, либо мы используем ошибочные методики создания таких архитектур.

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

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

Сложность

Чтобы определить причины неудач при использовании различных методик создания корпоративных архитектур, нужно понять, что общего между всеми неудачными попытками создания корпоративных архитектур. Что же общего у столь разных систем — у системы управления финансами Налогового управления, системы управления бизнесом Министерства обороны, системы управления действиями в чрезвычайных ситуациях Министерства национальной безопасности, системы управления ФБР Virtual Case File, системы управления бизнесом компании Макдоналдс, системы закупок компании Форд и системы управления каналом поставок компании KMart?

У всех этих систем только одна общая характеристика — сложность. Все эти системы обладают высокой сложностью. Я считаю, что основным недостатком архитектур FEAF и TOGAF и архитектуры Захмана является невозможность управления сложностью систем.

К сожалению, сложность — это не сиюминутная помеха. Можно с уверенностью сделать три предположения о будущем ИТ-отрасли:

Сложность будет только возрастать
Если мы не найдем методы управления сложностью, мы обречены на неудачу.
Существующие методы не работают.

В недавней статье, опубликованной в InformIT, Ричард Мур (Richard Murch) охарактеризовал положение дел следующим образом.

«Ничего не предпринимать, чтобы помешать дальнейшему повышению сложности ИТ-инфраструктур и архитектур — неприемлемо и безответственно. Если мы просто бросим на решение этой проблемы новых квалифицированных программистов и других специалистов, настанет хаос ... Пока пользователи и поставщики ИТ-систем решают проблему сложности похожим образом, подобные проблемы будут возникать снова и снова, мешая работе отрасли». [Mur]

Моделирование сложности

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

Лучшая модель сложности, которая мне известна, — это игральный кубик. Она интуитивно понятна, наглядна, предсказуема и математически обоснована. Я изложил основные положения этой модели в виде закона сложности Сешнса:

сложность системы является функцией числа возможных состояний системы.

Для понимания этого закона воспользуемся кубиком. Я буду сравнивать сложность двух случайных систем: системы А и системы Б, показанных на рис. 1. Система А состоит из одной двусторонней фигуры (т. е. «монеты»). Система Б состоит из одного кубика с шестью гранями (стандартный игральный кубик).

Рис. 1. Система А и система Б

Система А имеет два возможных состояния: орел и решка. Система Б имеет шесть возможных состояний: 1, 2, 3, 4, 5 и 6. В соответствии с законом сложности Сешнса система Б в 6/2 раз (т. е. в 3 раза) сложнее системы А. Даже если не вникать в математическое обоснование, это интуитивно понятно.

В общем случае число состояний системы, состоящей из D кубиков, каждый из которых имеет S сторон, равно S** D . С помощью этой формулы мы можем определять сложность других систем.

Теперь давайте сравним системы Б и В. Система Б, как и ранее, состоит из одного кубика с шестью гранями, а система В — из трех кубиков с шестью гранями, как показано на рис. 2.

Рис. 2. Система Б и система В

Число состояний системы Б по-прежнему равно 6**1 (или 6), а число состояний системы В равно 6**3 (т. е. 216). В соответствии с законом сложности Сешнса система В в 216/6 раз (т. е. в 36 раз) сложнее системы Б.

Если вы захотите предсказать результат броска кубиков в системе В, у вас будет 1 шанс из 216 угадать правильную комбинацию. Если вы захотите предсказать результат броска кубиков в системе Б, у вас будет 1 шанс из 6 угадать правильную комбинацию. Если вы сделаете серию предсказаний относительно обеих систем, в среднем вы сможете правильно предсказать состояние системы Б в 36 раз чаще, чем системы В. Поскольку система Б менее сложная, чем система В, она легче поддается прогнозированию.

Декомпозиция

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

Сравним две системы — систему В и систему Г, — каждая из которых состоит из трех шестигранных кубиков. В системе В кубики, как и ранее, находятся вместе, а в системе Г разделены на три подсистемы. Эти системы показаны на рис. 3.

Рис. 3. Система В и система Г

Предположим, мы можем использовать каждую из трех подсистем независимо (т. е. каждая подсистема будет представлять собой систему, подобную системе Б).

Мы знаем, что сложность системы В будет равна 216. Совокупная сложность системы Г определяется как сумма сложностей подсистем 1, 2 и 3. В соответствии с правилом S** D , сложность каждой подсистемы будет равна 6**1 или 6. Таким образом, сложность системы Г будет равна 6+6+6, или 18.

Если вас это не убеждает, представьте себе, что вам надо проверить правильность работы систем В и Г. При проверке системы В вам придется проверить правильность 216 различных состояний, а при проверке системы Г — только 6 различных состояний при проверке работы первой подсистемы, еще 6 — при проверке работы второй подсистемы и еще 6 — при проверке работы третьей.

Таким образом, сложность системы, состоящей из P подсистем, каждая из которых имеет сложность C, составляет C*P. Если каждая подсистема будет состоять только из одного кубика, эта формула примет вид S**1*D, что снижает сложность до S*D.

Теперь давайте обобщим полученный результат на все системы, прошедшие и не прошедшие декомпозицию. Чтобы упростить задачу, предположим, что подсистемы всегда состоят из одного кубика (как в случае с системой Г). При этом сложность системы, не проходившей декомпозицию (например, системы В) всегда равна S** D , а сложность системы, прошедшей декомпозицию (например, системы Г), всегда равна S*D.

Таким образом, вопрос можно свести к следующему: как соотносятся между собой формулы (S*D) и (S** D )? В таблице 1 приведены значения, вычисленные по формулам S*D (система с декомпозицией) и S** D (система без декомпозиции) для различных значений величин 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. Итерации с декомпозицией

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

Существующие инфраструктуры корпоративной архитектуры

История существующих стандартных инфраструктур корпоративной архитектуры (включая TOGAF, FEAF и модель Захмана) имеет много общего. Все эти архитектуры подверглись значительному влиянию парадигмы объектно-ориентированного проектирования и анализа (OODA).

Тот факт, что эти модели принадлежат к поколению OODA, очень важен, поскольку он означает, что все эти модели были созданы до появления сервис-ориентированных архитектур (SOA). Сегодня большинство крупных систем основано на концепции взаимодействия автономных приложений с использованием стандартов веб-служб (таких как SOAP, WS-Security и им подобных). Эта концепция тесно связана с парадигмой сервис-ориентированных архитектур, которая не была известна при создании разрабатываемых ранее моделей архитектуры.

Объектные технологии предназначены для создания приложений, а не корпоративных архитектур. Их основной недостаток в том, что невозможно управлять сложностью.

В 2004 году в крупномасштабном исследовании, посвященном сложности ИТ-систем, академия Royal Academy of Engineering и сообщество British Computer Society отметили следующее.

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

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

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

В инфраструктурах OODA зачастую декларировалась поддержка концепции итераций, однако между итерациями и итерациями с декомпозицией существует значительная разница. Концепция итераций, реализованная в OODA, больше похожа не на итерации, а на рекурсию, как показано на рис. 8. При использовании этой концепции сложность системы обрабатывается путем выделения небольших составляющих. Однако это не делает систему проще, а лишь уменьшает ее сложность в каждый конкретный момент времени.

Рис. 8. OODA-подход к корпоративным архитектурам

Итерации с декомпозицией имеют два существенных отличия от OODA-подхода. Первое (и самое главное) отличие состоит в том, что этот метод уменьшает сложность путем использования декомпозиции, а не пытается управлять сложностью, используя рекурсию. Второе отличие заключается в том, что при выполнении итераций с декомпозицией основное внимание уделяется скорости итераций, а не всеобъемлющему планированию. При этом мы исходим из предположения, что получим больше информации при выполнении действий, а не при их планировании. Этот подход показан на рис. 9.

Рис. 9. Создание корпоративной архитектуры с использованием итераций с декомпозицией

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

Преимущества подхода на основе итераций с декомпозицией

Применение подхода на основе итераций с декомпозицией позволяет получать коммерческую выгоду от проекта на более ранних этапах, чем при использовании OODA-подхода. Это становится возможным благодаря тому, что система создается по частям. Поскольку мы создаем вертикальные сегменты, каждый из которых имеет коммерческую ценность, итерации позволяют уменьшить время достижения положительного эффекта (TTV).

В мире бизнеса TTV это важнейшая характеристика. Даже более важная, чем уровень возврата инвестиций (ROI). ROI — это цель, которая ставится в долгосрочной перспективе. Для любого проекта, даже очень плохо организованного, разработанного со значительным превышением бюджета и не соответствующего требованиям бизнеса, можно по истечении длительного времени добиться высокого значения ROI, когда затраты на проект будут амортизированы. Вопрос в том, проработает ли компания столько времени?

TTV — это характеристика, ориентированная на более близкую перспективу. Хотя существует несколько определений TTV, я использую следующее: TTV — это промежуток времени между утверждением бюджета проекта и моментом, когда руководство убеждается, что проект оказывает положительное влияние на работу организации. Другими словами, это промежуток времени между расходованием средств и получением положительного эффекта. Значение ROI с TTV почти не связано.

Например, предположим, что руководство утвердило расходы в размере 20 млн долларов на реорганизацию службы поддержки заказчиков. Если использовать традиционный рекурсивный OODA-подход, положительный эффект будет получен только после того, как 20 млн будут полностью потрачены (и только если вам повезет). Однако вместо этого можно использовать итерационный подход с декомпозицией и разбить проект на вертикальные подсистемы, каждая из которых сама по себе является ценной с коммерческой точки зрения.

Предположим, что первая подсистема — это интерактивная библиотека, содержащая полезную информацию для заказчиков и обеспечивающая удобный доступ. Эта подсистема позволяет организации получать коммерческую выгоду задолго до завершения остальной части проекта и даже до достижения положительных значений ROI. Например, если вы сможете продемонстрировать, что в первый месяц библиотека на 20 % уменьшила время, которое затрачивала служба поддержки на решение вопросов заказчиков по телефону, вы докажете наличие положительного эффекта, даже если для достижения положительного значения ROI по проекту в целом необходимо несколько лет.

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

Быстрое получение положительного эффекта помогает проекту находиться «на виду» у руководства. С глаз долой, из сердца вон — именно это зачастую происходит с ИТ-проектами.

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

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

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

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

Эффективное управление ожиданиями — важная составляющая практически всех проектов. Итерационный подход с декомпозицией упрощает реагирование на возможные проблемы и позволяет более эффективно сообщать руководству о реальных ожидаемых результатах.

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

Четвертым преимуществом итерационного подхода с декомпозицией является представление результатов в виде проекта, структура которого похожа на структуру SOA. В отличие от огромных, неделимых монстров, зачастую порождаемых применением OODA-подхода, сервис-ориентированные архитектуры ֫— это набор взаимодействующих между собой небольших автономных служб, которые являются более гибкими и которые намного проще применять для повторного использования, взаимодействия и совместной работы, чем системы, полученные с помощью OODA.

И последнее. Итерационный подход с декомпозицией значительно упрощает дальнейшее расширение возможностей системы по сравнению с OODA-подходом. Это происходит в силу следующих трех факторов.

Использование итераций с декомпозицией позволяет создать значительно больше подсистем, чем при OODA-подходе. Это уменьшает психологическую склонность людей считать, что какая-то подсистема является уникальной и единственной для них, как и предоставляемая ею возможность внести желаемые изменения.
В проектирование каждой из этих подсистем вовлечено меньше людей, чем при использовании OODA-подхода. Это означает, что на каждой итерации необходимо узнать мнение меньшего числа людей о новых возможностях.
При использовании этого подхода основное внимание уделяется времени достижения положительного эффекта (TTV), а не коэффициенту возврата инвестиций (ROI), который является одной из основных характеристик при использовании OODA. Большинство людей думают, что для получения положительных значений ROI необходимы широкие функции приложения. Они полагают, что наличие большего числа функций означает, что приложением сможет воспользоваться больше людей, а чем больше людей им пользуются, тем больше от него «отдачи». Поэтому чрезмерная увлеченность ROI заставляет постоянно наращивать возможности систем.

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

Как видим, переход от методик создания корпоративной архитектуры на основе OODA-подхода к методикам на основе итераций с декомпозицией предоставляет организациям значительные преимущества. В том числе:

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

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

Слагаемые успеха

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

Правило 1. Сначала используйте простое решение

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

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

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

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

Таблица 2. Критерии выбора приоритета подсистем

Удобным средством определения приоритетов подсистем может стать схема приоритетов, показанная на рис. 10. На этой схеме каждая ось соответствует одному из критериев, перечисленных в таблице 2. При этом положительному влиянию соответствует зона, расположенная ближе к центру, а отрицательному — ближе к краям схемы.

Рис. 10. Схема приоритетов

Нарисовав схему приоритетов, расположите отметки «попаданий» вдоль каждой оси. Если, например, рассматриваемая подсистема имеет средний риск, поместите отметку на оси рисков в желтую зону. Завершив размещение отметок, вы увидите, какие проекты (подсистемы) следует разрабатывать в первую очередь.

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

Рис. 11. Сравнение схем приоритетов двух проектов

Правило 2. Используйте возможности для экономии «в мелочах»

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

К сожалению, эта теория не учитывает основополагающий закон управления проектами: закон снижения эффективности ресурсов. Чем больше людей участвует в работе над проектом, тем ниже эффективность проекта в целом. Этот закон является следствием известного закона Брукса. Более 30 лет назад Фред Брукс (Fred Brooks) был первым, кто заметил, что выделение дополнительных ресурсов для проекта, выполнение которого задерживается, лишь увеличивает задержку [Bro]. В 1999 году за открытие этого закона и другие достижения ему была присуждена Премия Тьюринга.

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

Безусловно, с увеличением масштабов мы можем добиться экономии. Однако настоящую экономию можно обеспечить при работе над небольшими, а не над крупномасштабными задачами.

Правило 3. Централизуйте взаимодействие, децентрализуйте реализацию

Многие организации разрабатывают излишне централизованные корпоративные архитектуры. Зачастую они создают отдел корпоративной архитектуры и предоставляют ему право принимать широкий круг решений. Подобная высокая централизация может вызвать рост бюрократизма и завести проект в тупик.

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

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

Давайте рассмотрим некоторые типичные ошибки при создании корпоративных архитектур.

Платформа. Многие организации пытаются выбрать стандартную платформу ПО и нередко ведут бесконечные споры, обсуждая, к примеру, Microsoft .NET, IBM' WebSphere или BEA WebLogic. Это бесполезная трата сил. Выбор платформы — это решение, которое касается реализации и не влияет на то, как будут организованы совместная работа и взаимодействие приложений на этой платформе. Если платформа удовлетворяет потребности организации в обеспечении взаимодействия, разработчики должны иметь возможность самостоятельно выбирать платформу для своих приложений.

Данные. Многие организации пытаются создать единый уровень данных, который будет использоваться всеми приложениями в организации. Эти попытки обычно требуют значительных затрат и редко бывают успешными. Методы хранения данных — это вопросы реализации приложения.

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

Совместное использование кода. Многие организации считают, что повторное использование компонентов обеспечивается благодаря совместному использованию кода. Удивительно, что это мнение существует, несмотря на неудачные попытки добиться желаемого результата в течение десятков лет. Лучший способ уменьшить объем кода в проекте — делегирование функций (например, с помощью веб-служб), а не совместное использование кода.

Интерфейсы API веб-служб. Многие организации обоснованно полагают, что использование веб-служб является важнейшим условием обеспечения взаимодействия. При этом нередко считается, что это означает обязательную стандартизацию методов использования приложениями интерфейсов API веб-служб. Однако на самом деле интерфейсы API веб-служб лежат намного «ниже» той области, с которой работают приложения. Как правило, приложения используют предоставляемый поставщиком промежуточный уровень (например, предоставляемый платформой Microsoft .NET уровень Windows Communications Framework), избавляющий приложения от необходимости обращаться к сложным интерфейсам API веб-служб. Поскольку каждая платформа использует собственный промежуточный уровень, этот уровень является особенностью реализации приложения.

Из всего вышесказанного можно сделать вывод: корпоративная архитектура и архитектура приложений — это разные понятия. Архитектура приложений определяет возможности приложения, которые должны соответствовать требованиям пользователей этого приложения. Это один из способов, позволяющих добиться экономии в малых масштабах (см. Правило 2. Используйте возможности для экономии «в мелочах»). А корпоративная архитектура описывает, каким образом эти приложения работают вместе, позволяя организации получать коммерческую выгоду.

Заключение

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

Ниже перечислены три основные причины столь частого повторения подобных дорогостоящих неудач. Первая причина — чрезмерное увлечение рекурсивными методиками создания архитектуры на основе объектно-ориентированного проектирования и анализа (OODA). Вторая причина — ошибочная уверенность в том, что создание корпоративной архитектуры означает создание подробного плана всей организации. Третья причина — неумение разбить сложные структуры на проекты меньшего размера, которыми можно более эффективно управлять.

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

В этой статье предложен новый подход к созданию корпоративной архитектуры, основанный на вертикальном позиционировании процессов организации, определении их приоритетов и выполнении итераций, при которых основное внимание уделяется времени достижения положительного эффекта (TTV). Такой подход можно назвать итерациями с декомпозицией. В отличие от рекурсивных методик данный подход снижает сложность системы в целом.

В статье приведены следующие три правила, помогающие добиться успеха при использовании описанной выше стратегии:

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

Применение итераций с декомпозицией предоставляет ряд преимуществ по сравнению с рекурсивными методиками. В том числе:

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

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

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

Глоссарий

.NET — обобщенное название семейства продуктов Microsoft, включающего инфраструктуру веб-служб.

Гибкость — параметр, характеризующий способность объекта (например, организации) быстро реагировать на изменение внешних условий.

Закон повторений Бойда — в сложных условиях быстрые повторения почти всегда обеспечивают лучшие результаты, чем углубленный анализ. Закон назван в честь полковника Джона Бойда.

Закон Брукса — выделение дополнительных ресурсов для проекта, выполнение которого задерживается, лишь увеличивает задержку. Приписывается Фредерику Бруксу.

Акт Клингера — Коэна. См. Закон о реформе управления информационными технологиями.

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

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

Инфраструктура корпоративной архитектуры — методология создания корпоративной архитектуры.

FEAF — см . Federal Enterprise Architectural Framework .

Federal Enterprise Architectural Framework (инфраструктура архитектуры федеральной организации, FEAF) — инфраструктура корпоративной архитектуры, используемая правительством США для описания взаимоотношений между государственными учреждениями и их ИТ-системами.

FEMA — федеральное агентство по управлению в чрезвычайных ситуациях. Орган правительства США, ответственный за реагирование на чрезвычайные ситуации.

GAO — см. Cчетная палата США.

Счетная палата США — орган правительства США, ответственный за контроль эффективности подразделений правительства США.

Закон о реформе управления информационными технологиями — закон, принятый Конгрессом США в 1996 году и требующий, чтобы все правительственные учреждения использовали эффективные стратегии и инфраструктуры развития и обслуживания ИТ-ресурсов.

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

IT — информационные технологии (ИТ).

Итерация — процесс, посредством которого сложное действие разбивается на несколько мелких, более простых составляющих.

Итерационная архитектура — подход к созданию систем, при котором проектирование, разработка и внедрение больших, сложных систем выполняются поэтапно.

Итерационный процесс — подход к гибкой разработке ПО, при котором процесс разработки программного обеспечения состоит из коротких итераций (повторений) процедур проектирования, реализации и оценки. Считается, что применение этого подхода позволяет создавать системы, которые более полно отражают изменяющиеся условия ведения бизнеса. Не следует путать с каскадной разработкой.

ITMRA — cм. Закон о реформе управления информационными технологиями.

Закон сложности — сложность системы зависит от числа возможных состояний системы. Часто используется для сравнения двух подходов к созданию системы.

Простое решение — термин, описывающий подмножество выборов, позволяющих достичь наибольшего положительного эффекта с наименьшими затратами.

Объектно-ориентированное проектирование и анализ — инфраструктура архитектуры, основанная на объектно-ориентированной рекурсивной декомпозиции.

OODA — см. Объектно-ориентированное проектирование и анализ.

OOPA (НОПД) — наблюдение, ориентация, планирование, действие (Observe, orient, plan, act). Циклический процесс, впервые использованный полковником Джоном Бойдом (John Boyd) при описании действий истребителей. Бойд выделял этапы наблюдения, ориентации, реализации и действия. По мнению Бойда, этот цикл постоянно повторяется, и тот, кто выполняет его быстрее, одерживает победу над тем, кто выполняет его более полно.

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

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

Унифицированный процесс Rational (RUP) — процесс разработки ПО с помощью инструментальных средств IBM/Rational.

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

Избыточность — наличие одних и тех же функций в нескольких системах.

Уровень возврата инвестиций — числовая характеристика (в процентах) коммерческой ценности проекта, рассчитываемая как отношение величины роста прибыли (вследствие увеличения доходов или снижения расходов) к величине затрат на проект. Например, если проект, на который потрачено 100 тыс. долл., позволил увеличить прибыль на 200 тыс. долл., то уровень возврата инвестиций составит 200 %.

ROI — см. Уровень возврата инвестиций.

SOA — см. Сервис-ориентированная архитектура.

Закон Сарбэйнса — Оксли. Закон, принятый Конгрессом США в 2002 году и направленный на борьбу с мошенничеством в бухгалтерской деятельности компаний. Закон Сарбэйнса — Оксли требует проведения строгого аудита финансовой информации и вводит личную ответственность руководителей финансовых подразделений.

Служба — см. Веб-служба.

Сервис-ориентированная архитектура — архитектура для обеспечения взаимодействия автономных систем на основе технологии веб-служб.

SOX — см.Закон Сарбейнса — Оксли.

TAFIM (архитектура технического обеспечения для управления информацией, Technical Architecture Framework for Information Management) — архитектура, разработанная Министерством обороны США и официально отмененная в 2000 году.

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

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

TOGAF (инфраструктура архитектуры Open Group) 8.1 — инфраструктура архитектуры, разработанная консорциумом Open Group.

TTV — см. Время достижения эффекта.

Веб-служба — автономная программная система, отвечающая на запросы других независимых программных систем с использованием непатентованного формата сообщений и транспортного протокола. Обычно используется формат сообщений SOAP.

Рабочий процесс — процесс продвижения задания в организации как задачи высокого уровня до выполнения (например, обработка страхового требования).

Инфраструктура Захмана для корпоративных архитектур — инфраструктура архитектуры, в которой организация моделируется тридцатью ячейками, каждая из которых представляет собой пересечение перспективы и абстракции.

Список источников

Arm. Armour F.J., Kaisler S.H., Liu S.Y. A big-picture look at enterprise architectures («Обобщенное представление архитектуры организации») // IT Professional — янв/фев 1999 г. — том 1, выпуск 1 — С. 35–42.

Bro. Frederick Phillips Brooks The Mythical Man-Month; Essays on Software Engineering («Мифический человеко-месяц, или Как создаются программные системы») // Addison-Wesley, к 20-й годовщине публикации — 1995.

Boy. Хороший обзор работы Джона Бойда см. в работе Franklin C. Spinney Genghis John («Чингиз Джон») // Proceedings of the U. S. Naval Institute — июль 1997 — С. 42–47.

Car . Nicholas G. Carr Does Not Compute (« Несчитается ») // New York Times — 22 января 2006 г .

Cha . Robert N. Charette Why Software Fails (« ПочемувработеПОвозникаютсбои ») // IEEE Spectrum — сентябрь 2005 г .

Cli. Закон о реформе управления информационными технологиями, вторая сессия 104-го Конгресса США.

CMU. Университет Карнеги — Меллон, www.sei.cmu.edu/architecture/glossary.html.

Gov. Эта цитата может встречаться в разных источниках. Например, по адресу: www.cio.gov/documents/FINAL_White_Paper_on_EA_v62.doc.

Fea. Инфраструктура FEAF описана во многих источниках. Например , вруководстве A Practical Guide to Federal Enterprise Architecture (« Практическоеруководствопоархитектуре Federal Enterprise Architecture») поадресу : http://www.gao.gov/bestpractices/bpeaguide.pdf .

GAO1. Отчет GAO для министра финансов США. FINANCIAL AUDIT IRS's Fiscal Years 2004 and 2003 Financial Statements (« ФИНАНСОВЫЙАУДИТ . Финансовые отчеты Налогового управления США за 2003 и 2004 финансовый год»), ноябрь 2004.

GAO2. Отчет для подкомитета по государственному управлению, финансам и отчетности комитета по реформированию государственного управления Палаты представителей. DOD BUSINESS TRANSFORMATION - Sustained Leadership Needed to Address Long-standing Financial and Business Management Problems («ИЗМЕНЕНИЯ В КОММЕРЧЕСКОЙ ДЕЯТЕЛЬНОСТИ МИНИСТЕРСТВА ОБОРОНЫ США — потребность в постоянном руководстве для разрешения долгосрочных финансовых проблем и проблем управления коммерческой деятельностью»), июнь 2005.

GAO3. Отчет GAO для подкомитета по технологиям, информационной политике, межгосударственным отношениям и сбору сведений комитета по реформированию государственного управления Палаты представителей. HOMELAND SECURITY Efforts Under Way to Develop Enterprise Architecture, but Much Work Remains («МИНИСТЕРСТВО НАЦИОНАЛЬНОЙ БЕЗОПАСНОСТИ.Корпоративная архитектура разрабатывается, однако впереди еще много работы»), август 2004.

For. Patricia Keefe Oops! Ford and Oracle mega-software project crumbles («Бах! Грандиозный программный проект Ford и Oracle провалился») // ADTMag — 11 ноября 2004.

Kma . David F . Carr и Edward Cone Code Blue («Экстренная ситуация») // Baseline — ноябрь/декабрь 2001.

Mac . Larry Barrett и Sean Gallagher McDonald's: McBusted(«Неудача Макдоналдс») // Baseline — 2 июля 2003.

Mur. РичардМур Managing Complexity in IT, Part 1: The Problem («Управление сложностью в ИТ. Часть 1: проблема») // InformIT — 1 октября 2004.

Roy . The Challenges of Complex IT Projects («Проблемы сложных ИТ-проектов»). Отчет рабочей группы Royal Academy of Engineering и British Computer Society, апрель 2004 г.

TAF . Министерство обороны США. Technical Architecture Framework For Information Management (TAFIM) Volumes 1–8, Version 2.0. («Архитектура технического обеспечения для управления информацией, тома 1–8, версия 2.0») // Reston, VA — DISA Center for Architecture — 1994.

TOG . The Open Group Architectural Framework (инфраструктура архитектуры Open Group, TOGAF ) версии 8.1 Enterprise Edition см. по адресу: www.opengroup.org.

Wiki. Википедия, http://en.wikipedia.org/wiki/Enterprise_architecture.

Zac. J.A. Zachman A framework for information systems architecture («Инфраструктура для архитектуры информационных систем») // The IBM Systems Journal — 1987 — том 26, № 3, С. 276–292.

Управление архитектурой предприятия :: Новости

четверг, 27 ноября 2014 г.