Сравнение четырех ведущих методологий построения архитектуры предприятия

http://msdn.microsoft.com/ru-ru/library/ee914379.aspx
Роджер Сешнс, Компания ObjectWatch, Inc., Май 2007 г.

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

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

Итог: высокие затраты, низкая эффективность. Эти проблемы, впервые выявленные 20 лет назад, сегодня достигли критической точки. Стоимость и сложность ИТ-систем выросли экспоненциально, а реальная польза от них резко снизилась.

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

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

• Структура Захмана для архитектуры предприятий — хотя эта модель определяется как , более правильно называть ее .
• TOGAF (The Open Group Architectural Framework) — хотя эта модель называется , фактически она является .
• Архитектура федеральной организации — эту модель можно рассматривать как либо как по созданию архитектуры предприятия.

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

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

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

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

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

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

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

Введение

2007 год ознаменовался 20-летним юбилеем методологий построения архитектуры предприятия. За это время было разработано множество методологий. Сегодня доминирующее положение занимают четыре методологии: структура Захмана для архитектуры предприятий, методология TOGAF (The Open Group Architecture Framework), архитектура федеральной организации (FEA) и методология Gartner (ранее именуемая Meta Framework).

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

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

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

По мере увеличения сложности систем возрастает роль планирования. Это легко проиллюстрировать на примере зданий. Когда Генри Дэвид Торо строил свой маленький домик у пруда Уолден (рис. 1), ему не нужны были архитекторы ввиду исключительной простоты задачи. Однако при застройке Нью-Йорка (рис. 2) ни о какой простоте не может быть и речи, поэтому требуется множество архитекторов.

Рис. 1. Домик Торо на берегу пруда Уолден, рисунок сестры писателя Софии Торо

Рис. 2. Нью-Йорк

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

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

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

Конечно, привлечение градостроителя не гарантирует возведения пригодного для жилья города, но шансы на успех значительно выше. Точно так же привлечение архитектора предприятий не гарантирует создания успешной архитектуры предприятия. Можно привести множество примеров неудачной архитектуры предприятия в современном мире, и все эти архитектуры были созданы архитекторами предприятий (таких примеров десятки!). Методологии построения архитектуры полезны, однако их возможности ограничены. В этом документе также будут рассмотрены причины подобных неудач и способы избежать их.

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

Рассмотрим, к примеру, две методологии, которые позиционируются как структуры архитектуры предприятия: структуру Захмана для архитектуры предприятий и методологию TOGAF (The Open Group Architectural Framework). Эти две методологии имеют мало общего друг с другом, за исключением слов предприятие,архитектура и структура.

Прежде всего, начнем с определения используемых в данном документе терминов. Определения, обозначенные звездочкой (*), взяты в основном из спецификации IEEE-1471-2000 [01] и будут использоваться везде, где они существуют и имеют смысл.

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

архитектурный артефакт — конкретный документ, отчет, аналитический отчет, модель или любой другой компонент архитектурного описания

архитектурное описание* — набор объектов (артефактов), предназначенных для документирования архитектуры

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

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

архитектурный процесс — определенная последовательность действий, направленных на создание архитектуры либо архитектурного описания

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

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

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

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

Краткая история архитектуры предприятия

Понятие «архитектура предприятия» впервые появилось в 1987 г. в статье Дж.А. Захмана «Структура архитектуры информационных систем», опубликованной в журналеIBM Systems Journal. В этой статье автор изложил свое видение архитектур предприятий и связанных с ними проблем, которое задало направление развития на последующие 20 лет. В качестве проблемы было обозначено управление сложностью распределенных систем. Захман говорит:

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

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

Захман внес основной вклад в разработку архитектуры предприятия Министерством обороны США. Эта попытка была предпринята в 1994 г., а сама концепция получила название «Базовая архитектура технического обеспечения для управления информацией» (TAFIM) [03].

Преимущества, обеспечиваемые такими архитектурами предприятий, как TAFIM (например, приведение в соответствие технических проектов с потребностями бизнеса), не были отмечены никем, кроме Конгресса США. В значительной степени благодаря впечатлению, произведенному концепцией TAFIM, Конгресс в 1996 г. принял закон, известный как акт Клингера — Коэна от 1996 г. [04], а также как реформа управления информационными технологиями, в котором всем федеральным агентствам было предписано принять меры по повышению эффективности инвестиций в ИТ. Для надзора за выполнением этого закона был сформирован совет директоров по информационным технологиям, в который вошли директора по информационным технологиям из всех основных правительственных органов.

В апреле 1998 г. совет директоров по информационным технологиям начал работу над первым крупным проектом, структурой архитектуры федеральной организации (FEAF). Версия 1.1 [05] данной структуры была выпущена в сентябре 1999 г. В этом документе содержался ряд инновационных идей, например идея «сегментированных архитектур» — то есть рассмотрение в архитектурном аспекте сегментированных подмножеств крупного предприятия.

Через некоторое время полномочия совета директоров по информационным технологиям по архитектуре федеральной организации были переданы Административно-бюджетному управлению. В 2002 г. Административно-бюджетное управление переработало методологию FEAF и переименовало ее в архитектуру федеральной организации (FEA). Методология FEA будет подробно рассмотрена ниже в соответствующем разделе.

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

Только 20 из 96 проверенных агентств заложили у себя хотя бы основу для эффективного управления архитектурой. Более того, хотя в 22 агентствах увеличили степень соответствия требованиям с 2001 г., в 24 степень соответствия снизилась, а в 47 осталась без изменений. [06]

С января 2005 г. Бюджетно-контрольное управление (не путать с Административно-бюджетным управлением) серьезно наказало ряд правительственных агентств за невыполнение предписаний по внедрению и использованию архитектуры предприятия. В качестве примера можно привести ФБР [07], Министерство обороны [08], Министерство национальной безопасности [09] и НАСА [10].

В 1998 г., четыре года спустя после разработки TAFIM (помните о TAFIM?) и два года спустя после оформления этой методологии в виде акта Клингера — Коэна, методология TAFIM была официально отменена Министерством обороны.

Все наработки по TAFIM были преобразованы в открытую группу, а затем — в новый стандарт, известный в настоящее время под названием TOGAF (The Open Group Architectural Framework). Стандарт TOGAF будет рассмотрен ниже в соответствующем разделе.

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

К 2005 г. компания Gartner стала одной из наиболее влиятельных организаций, занимающихся консалтингом на уровне директоров по информационным технологиям. Однако в области разработки архитектуры предприятия наиболее известной ИТ- и консалтинговой компанией была не Gartner, а Meta Group.

Компания Gartner пыталась создать рекомендации по разработке архитектуры предприятия, однако ей не удалось превзойти Meta Group. В 2005 г. компания Gartner решила, что, раз ей не удается конкурировать с Meta Group, можно поступить иначе: компания Gartner приобрела компанию Meta Group.

После приобретения Meta Group компания Gartner/Meta потратила год на то, чтобы разобраться, какой вклад внесла каждая из компаний в методологию разработки архитектуры предприятия. Две компании обсуждали, как наилучшим образом объединить свои заметно различающиеся подходы.

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

На рис. 3 эта история представлена по этапам на фоне временной шкалы. Мы переходим к современному этапу развития архитектуры предприятия. Рассмотрим более подробно основные современные методологии и приведем вводные данные, которые будут использоваться далее.

Рис. 3. Временная шкала архитектуры предприятия

Пример внедрения

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

Компания MedAMore представляет собой сеть аптек. Компания была основана в 1960 г. как региональная сеть. В 1995 г. компания разработала инновационное программное обеспечение для высокоэффективного управления аптеками. Это ПО получило название MedAManage (MAM). В MAM был реализован ряд инновационных бизнес-идей, например управление отношениями с пациентами, управление запасами, автоматизированное выставление счетов за услуги страховых компаний и даже оптимизация ресурсов.

ПО MAM включало в себя три программы: MAM/Store, которая запускалась на персональном компьютере в аптеке, MAM/Warehouse, которая запускалась на сервере на региональном складе, и MAM/Home, которая запускалась на мощном сервере в головном офисе.

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

До 2000 г. дела у компании MedAMore шли довольно хорошо, в частности, благодаря экономии, которую обеспечивала система MAM. Компания MedAMore решила расширяться. Для этого она приобрела три региональные сети аптек. После этого приобретения компания MedAMore расширила область охвата на юго-восток США.

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

• В программе MAM/Store требовалось обеспечить поддержку региональной специфики. Например, в различных регионах необходимо было обеспечить поддержку различных планов страхования, а для этого требовалось внести изменения в модуль MAM/Store.
• На региональных складах, приобретенных вместе с региональными сетями, использовались различные способы приема заказов от розничных точек и различные процедуры поставок от оптовиков. Для поддержки этих различий требовалось внести изменения в модуль MAM/Warehouse.
• Подход к совместному использованию данных на основе передачи файлов, который хорошо работал, когда компания MedAMore владела 30 аптеками, одним региональным складом и головным офисом, оказался неудобным для координации работы 200 аптек, четырех региональных складов, двух филиалов и одного головного офиса. Файлы часто доставлялись слишком поздно, иногда не доставлялись вообще, а иногда — многократно. Это затрудняло доступ головного офиса к надежной и актуальной финансовой информации, особенно по продажам и складским запасам.

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

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

Программу MedAManage (управление в медицине) впору было переименовывать в MedANightmare (медицинский кошмар). Отладка была затруднена. Сборка программного обеспечения превратилась в пытку. Установка новых систем приводила к серьезным перебоям в работе.

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

Это привело к расколу между бизнес- и ИТ-подразделениями компании MedAMore. Бизнес-подразделение считало, что ИТ-подразделение препятствует развитию бизнеса. Техническое подразделение считало, что бизнес-подразделение выдвигает невыполнимые требования и обвиняло его в том, что оно не советуется с ИТ-специалистами перед тем как вступить в переговоры о новых приобретениях.

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

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

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

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

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

По рекомендации Ирмы Кэт назначила собрание, на котором должен был присутствовать Брет, вице-президент по бизнесу. Кэт объявила, что она решила создать общую архитектуру предприятия MedAMore, которая объединила бы сотрудников технического и бизнес-подразделений. Эта общая архитектура предприятия получила название MedAMore-Enterprise Architecture (MAM-EA). Архитектура MAM-EA позволила бы управлять инвестициями в ИТ и гарантировать, что каждый доллар, вложенный в ИТ, будет приносить максимальную пользу бизнесу.

Кэт знала, что разработка архитектуры MAM-EA — это серьезное решение, принятие которого ставит на карту судьбу компании MedAMore. Представление MAM-EAдолжно было работать. Успех предприятия зависел от Брета (бизнес-подразделение) и Ирмы (ИТ-подразделение).

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

Структура Захмана для архитектуры предприятий

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

Каркас для поддержки или заключения других объектов, особенно скелетной поддержки, используемой в качестве основы для какой-либо конструкции; Внешняя рабочая платформа; леса; Фундаментальная структура (в письменных работах); Набор предположений, концепций, характеристик и практик, составляющих способ представления реальности. [11].

С другой стороны, таксономия определяется следующим образом:

Классификация организмов в упорядоченной системе, отражающая естественные связи; Наука, законы и принципы классификации; систематика; Разбиение на упорядоченные группы или категории [12]

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

Джон Захман так описал свою работу:

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

Многие сторонники структуры Захмана рассматривают ее как междисциплинарную, распространяющуюся далеко за пределы ИТ. Например, в одной популярной книге, посвященной методологии Захмана, говорится следующее:

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

Сам Джон Захман сказал мне в своем недавнем интервью следующее:

«...схема структуры использовалась несколько тысяч лет, и я уверен, будет использоваться еще несколько тысяч лет. Меняется только наше понимание структуры и принципы ее использования в проектировании предприятий и производстве». [15]

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

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

В исходной статье Захман говорит следующее:

«...каждое архитектурное представление отличается от других по существу, а не только уровнем детализации». [16]

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

В первой статье и последующей работе в 1992 г. [17] Захман предложил шесть описательных аспектов (данные, функция, сеть, люди, время и мотивация) и шесть игроков (планировщик, владелец, проектировщик, строитель, субподрядчик и предприятие). Эти два измерения можно представить в виде таблицы, как показано на рис. 4.

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

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

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

«Мы испытываем трудности при обсуждении друг с другом архитектуры информационных систем, поскольку вместо единой архитектуры используется набор архитектурных представлений. При таком положении дел неправы оба участника обсуждения. Архитектуры различны. Они взаимно дополняют друг друга. Существуют веские причины выделить ресурсы на разработку каждого архитектурного представления. Если какие-либо архитектурные представления не разработаны, организация подвергается риску». [18]

Историческая важность структуры Захмана была рассмотрена в разделе, посвященном истории архитектуры предприятия. Ниже будет рассмотрена фактическая структура и ее использование для построения архитектуры MAM-EA и решения проблемы, изложенной в разделе «Пример внедрения».

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

Рис. 4. Таблица Захмана

Как видно из рис. 4, таблица Захмана состоит из 36 ячеек — по одной для каждого сочетания точки зрения игрока (например, владельца бизнеса) и описательного аспекта (например, данных). При перемещении по таблице по горизонтали (например, слева направо) мы получаем различные описания системы — с точки зрения одного и того же игрока. При перемещении по таблице по вертикали (например, сверху вниз) мы рассматриваем один аспект, но изменяем игрока, с точки зрения которого рассматривается этот аспект.

Таблица Захмана может помочь компании MedAMore в разработке архитектуры MAM-EA тремя способами.

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

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

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

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

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

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

Итак, существует пять способов использования таблицы Захмана при разработке архитектуры MAM-EA. Таблица Захмана позволяет:

• Убедиться в том, что точка зрения каждого заинтересованного лица была рассмотрена в каждом описательном аспекте.
• Улучшить артефакты архитектуры MAM-EA путем точной подгонки описательных аспектов под конкретную аудиторию.
• Убедиться в том, что все бизнес-требования Брета сводятся к технической реализации.
• Убедить Брета в том, что технические специалисты Ирмы не планируют реализовывать бесполезные функции.
• Убедить Ирму в том, что сотрудники бизнес-подразделения учитывают при планировании интересы ИТ-специалистов.

Однако таблица Захмана сама по себе не является полным решением для компании MedAMore. Существует слишком много проблем, которые необходимо устранить для успешного создания архитектуры MAM-EA, но невозможно устранить с помощью методологии Захмана. Методология Захмана не дает пошаговых инструкций по созданию архитектуры. Методология Захмана даже не позволяет определить, является ли создаваемая архитектура лучшей из возможных. Кроме того, методология Захмана не позволяет определить, необходимо ли вообще создавать новую архитектуру. Для решения этих и других проблем необходимо обратиться к другим методологиям.

Методология TOGAF (The Open Group Architecture Framework)

TOGAF — этоаббревиатураот The Open Group Architecture Framework ( структураархитектуры The Open Group). Методология TOGAF принадлежит консорциуму The Open Group [19]. Представление архитектуры предприятия в методологии TOGAF показано на рис. 5.

Рис. 5. Архитектура предприятия TOGAF

Как показано на рисунке, в модели TOGAF архитектура предприятия подразделяется на четыре категории:

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

Архитектура приложений — описывает структуру конкретных приложений и их взаимодействие друг с другом

Архитектура данных — описывает структуру корпоративных хранилищ данных и процедуры доступа к ним

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

Модель TOGAF позиционируется как «структура», однако наиболее важным ее компонентом является методика разработки архитектуры (ADM). Эта методика представляет собой рецепт по созданию архитектуры. Рецепт можно классифицировать как процесс. С учетом того, что методика разработки архитектуры является наиболее значимой составляющей модели TOGAF, я рассматриваю TOGAF в целом как архитектурный процесс, а не как архитектурную структуру (как позиционирует TOGAF консорциум The Open Group) или методологию (как позиционируется методика разработки архитектуры).

Как архитектурный процесс модель TOGAF дополняет модель Захмана — которая, напомню, классифицируется в данной статье как архитектурная таксономия. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

В модели TOGAF мир архитектуры предприятия рассматривается как континуум архитектур, от максимально обобщенных до максимально специализированных. Этот континуум называется континуумом предприятия. Процесс создания конкретной архитектуры предприятия, например MAM-EA, рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления такого перехода.

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

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

Следующий уровень специализации в модели TOGAF называется отраслевыми архитектурами. Эти принципы характерны для предприятий, занятых в одной сфере деятельности, например в случае с MedAMore — для всех фармацевтических компаний.

Самый высокий уровень специализации в модели TOGAF называется архитектурами организаций. Это архитектуры конкретных предприятий, например MedAMore.

На рис. 6 показано соотношение между континуумом предприятия и методикой разработки архитектуры (ADM).

Рис. 6. Континуум предприятия в модели TOGAF

В модели TOGAF на уровне фундаментальных архитектур определяется ряд баз знаний. Вы можете столкнуться с двумя из них: технической эталонной моделью (TRM) иинформационной базой стандартов (SIB). Техническая эталонная модель является рекомендуемым описанием общей ИТ-архитектуры. Информационная база стандартов представляет собой набор стандартов и псевдостандартов, которые консорциум The Open Group рекомендует использовать при построении ИТ-архитектуры.

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

Для таких организаций, как MedAMore, модель TOGAF в значительной степени сводится к методике разработки архитектуры. Сотрудники MedAMore будут работать с континуумом предприятия, информационной базой стандартов и технической эталонной моделью (а также с рядом других возможностей TOGAF); именно поэтому эти возможности и были рассмотрены здесь. Однако для каждодневного создания архитектуры предприятия в основном будет использоваться методика разработки архитектуры, высокоуровневое представление которой показано на рис. 7.

Рис. 7. Методика разработки архитектуры (ADM) в модели TOGAF

Как показано на рис. 7, методика разработки архитектуры в модели TOGAF состоит из восьми этапов, которые циклически повторяются после первой «накачки». Далее эти этапы будут рассмотрены на примере MedAMore. Однако перед тем как компания MedAMore сможет приступить к использованию методики разработки архитектуры, ей необходимо изучить модель TOGAF. Изучить модель TOGAF можно двумя способами.

Во-первых, компания MedAMore может изучить модель TOGAF самостоятельно. Компания MedAMore может загрузить документацию по TOGAF [20] — в ней достаточно подробно описаны все возможности TOGAF, в том числе методика разработки архитектуры. Также можно приобрести книги по TOGAF [21]. О модели TOGAF доступно больше информации (как бесплатной, так и за умеренную цену), чем обо всех остальных методологиях построения архитектуры вместе взятых.

Во-вторых, компания MedAMore может обратиться к экспертам по TOGAF. На рынке работает множество консультантов по TOGAF, обладающих сертификатами Open Group [22]. Поскольку руководство компании MedAMore хочет свести все риски к минимуму, оно принимает решение обратиться к консультанту по TOGAF. Компания MedAMore обратилась к Тэри, которая является архитектором TOGAF с сертификатом Open Group. Напомним, что другими игроками в компании MedAMore являются Кэт, исполнительный директор MedAMore, Брет, вице-президент по бизнесу, и Ирма, директор по информационным технологиям.

На подготовительном этапе Тэри встречается с основными игроками в компании MedAMore и рассказывает им о процессе TOGAF. Она преследует три основные цели:

• Убедиться в том, что процесс устраивает всех игроков
• Если необходимо, изменить процесс TOGAF в соответствии с корпоративной культурой MedAMore
• Разработать систему управления для надзора за последующей разработкой архитектуры в MedAMore

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

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

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

После получения «Запроса на разработку архитектуры» (или аналогичного документа) Тэри (консультант по TOGAF) переходит к этапу А. На этом этапе Тэри предстоит убедиться в том, что проект надлежащим образом поддерживается компанией MedAMore, определить область действия проекта, выявить ограничения, задокументировать бизнес-требования и разработать высокоуровневые определения как для базовой (начальной), так и для целевой (желаемой) архитектуры.

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

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

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

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

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

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

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

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

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

Это хороший совет для любой методологии построения архитектуры. Таким образом, Тэри следует выделить проекты, которые можно реализовать с минимальными затратами и максимальной отдачей. Для поиска таких проектов рекомендуется изучить «болевые точки» организации, изначально обозначенные Кэт (исполнительным директором MedAMore). Это позволит принять стратегию развития предприятия на базе архитектуры. Описанные выше «болевые точки» включают трудности в обеспечении поддержки специализации на уровне регионов и складов и ненадежный обмен данными.

Этап Е тесно связан с этапом Д. На этом этапе Тэри работает с руководством компании MedAMore's, чтобы упорядочить по приоритетам проекты, выбранные на этапе Д, с учетом не только затрат и выхода (определенных на этапе Д), но и факторов риска.

На этапе Ж Тэри на основе упорядоченного по приоритетам списка проектов создает спецификации архитектуры для проектов реализации. Эти спецификации включают критерии приемки и списки рисков и проблем.

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

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

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

«Методология TOGAF — это не только и не столько создаваемые документы; фактически она в меньшей степени ориентирована на шаблоны документов, а в большей — на то, что мы получаем на входе и на выходе». [23]

Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:

Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия. [24]

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

Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии).

Архитектура федеральной организации (FEA)

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

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

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

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

Очевидно, что FEA представляет собой нечто большее, чем набор моделей. Эта методология включает в себя все необходимое для построения архитектуры предприятия даже для самой сложной, пожалуй, организации в мире — Правительства США. По заявлению управления по реализации программы FEA (FEAPMO), методология FEA в целом обеспечивает:

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

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

Архитектура предприятия с точки зрения FEA

С точки зрения FEA, архитектура предприятия состоит из отдельных сегментов. Эта идея была впервые изложена в FEAF [26]. Сегмент представляет собой один из основных аспектов бизнеса, например трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные.

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

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

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

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

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

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

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

Последнее примечание относительно сегментов. Хотя сегменты функционируют на политическом уровне (то есть на уровне агентств), они определяются на уровне предприятия (то есть на уровне правительства). Службы предприятия, естественно, функционируют и определяются на уровне предприятия.

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

Рис. 8. Схема сегментов федерального правительства

Эталонные модели FEA

Все пять эталонных моделей FEA предназначены для формирования единого языка. Цель — упростить взаимодействие, сотрудничество и совместную работу, минуя границы политико-административного деления. Согласно заявлению управления по реализации программы FEA (FEAPMO):

«Методология FEA включает в себя набор взаимосвязанных "эталонных моделей", предназначенных для упрощения анализа деятельности агентств и выявления дублирующих инвестиций, несоответствий и возможностей для совместной работы внутри агентств и между ними. Совместно эталонные модели [образуют] структуру для единообразного описания важных элементов методологии FEA». [28]

Зачем нужен общий язык? Рассмотрим следующий диалог:

Джеймс: «Не дашь мне на время лампу?»

Роджер: «У меня ее нет».

Джеймс: «А где ее можно купить?»

Роджер: «В магазине бытовой техники».

Итак, Джеймс отправляется в магазин и покупает то, что хотел. Он возвращается к Роджеру.

Роджер: «Ну что, купил лампу?»

Джеймс: «Да, вот она».

Роджер: «Это же не лампа! Это фонарик. Почему ты сразу не сказал? Я бы дал тебе на время свой».

Джеймс: «А почему ты не сказал, что он у тебя есть?»

Проблема заключается в том, что Джеймс приехал из Англии, где фонарь (англ. flashlight) называют лампой (англ. torch). Когда же я слышу слово лампа (англ. torch), я представляю паяльнуюлампу(англ. blowtorch). Хотя мы оба говорим по-английски, это не значит, что мы говорим на одном и том же языке. В результате Джеймс зря сходил в магазин и потратил деньги на то, что мог бы позаимствовать у меня.

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

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

В итоге Налоговое управление разрабатывает систему с нуля вместо того, чтобы просто изменить уже готовую (и оплаченную) систему, используемую в Управлении правительственной печати. При этом Налоговое управление выбрасывает на ветер гораздо больше денег, чем потратил Джеймс на ненужный фонарь.

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

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

Эталонная модель компонентов (CRM) дает ИТ-представление систем, поддерживающих бизнес. Например, в эталонной модели компонентов определяетсяаналитическая система, упомянутая выше в гипотетическом описании взаимодействия между Налоговым управлением и Управлением правительственной печати. [30]

В Технической эталонной модели (TRM) определяются различные технологии и стандарты, используемые при построении ИТ-систем. Например, в этой модели HTTPопределяется как протокол, который является подмножеством служебного транспорта, который, в свою очередь, является подмножеством служебного доступа и доставки. [31]

В эталонной модели данных (DRM) определяются стандартные способы описания данных. Например, сущность в этой модели определяется как нечто,обладающееатрибутами и участвующее в отношениях. [32]

В эталонной модели производительности (PRM) определяются стандартные способы описания полезности, обеспечиваемой архитектурами предприятий. Например,качество в этой модели определяется как область измерений, которая, в свою очередь, определяется как «степень соответствия технологии требованиям к функциональности или возможностям». [33]

Процесс FEA

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

• Этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации.
• Этап 2. Архитектурное определение: задание желаемого состояния сегмента, документация целевых показателей производительности, рассмотрение альтернатив и разработка архитектуры предприятия для сегмента, в том числе архитектуры бизнеса, архитектуры данных, архитектуры служб и технологической архитектуры.
• Этап 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта.
• Этап 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контрольные точки и показатели производительности для оценки успешности проекта.

Оценка успешности в методологии FEA

Структура FEA для оценки успеха в использовании архитектуры предприятия описана в документе «Структура оценки архитектуры предприятия по программе FEA 2.1» [35]. Уровень готовности федеральных агентств оценивается по трем категориям:

·          Завершенность архитектуры — уровень готовности собственно архитектуры

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

·          Результаты использования архитектуры — преимущества, достигнутые благодаря использованию архитектуры

Административно-бюджетное управление присваивает каждому агентству рейтинг успеха на основе оценок по каждой категории и совокупному показателю следующим образом.

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

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

Рис. 9. Рейтинги Административно-бюджетного управления для оценки завершенности архитектуры, адаптированные автором (Роджером Сешнсом) для частного сектора экономики

Применение методологии FEA к компании MedAMore

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

Кэт обращается к Фреду, эксперту по FEA (предположим, что такие эксперты существуют, хотя на момент написания этой статьи методологии FEA еще не исполнилось и года!). Задача Фреда заключается в том, чтобы показать компании MedAMore, как можно применить методологию FEA — конечно, не в чистом виде, а в том виде, в каком она применима к частному сектору экономики. Кэт знакомит Фреда с Бретом (вице-президентом по бизнесу) и Ирмой (директором по информационным технологиям) и ставит им задачу разработать anMEA — методологию FEA, адаптированную для компании MedAMore.

Помните, что Кэт довольно сильно рискует. На сегодняшний день ни одна компания не пыталась применить методологию FEA в частном секторе экономики, а опыт использования FEA в государственном секторе можно назвать в лучшем случае номинальным.

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

Далее Фред займется построением в MedAMore управляющей структуры, эквивалентной FEAPMO. Эта структура будет называться MEAPMO. Методология MEA, включая процессы, модели и собственно архитектуру, будет находиться в ведении MEAPMO.

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

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

К этому моменту уже проделана большая работа и получены первые результаты. Далее Фред, скорее всего, начнет первую итерацию процесса разработки архитектуры сегмента. Процесс FEA является хорошей отправной точкой, однако требует изменений с учетом специфики MedAMore на уровне деталей (например, необходимо указать состав рабочей группы и форму представления артефактов).

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

После завершения работы над первым сегментом Фред принимает решение оценить эффективность использования методологии MEA в других группах в компании MedAMore. Ему необходим критерий оценки эффективности различных групп в компании MedAMore. Для этого Фред поручает MEAPMO разработать эквивалент «Структуры оценки архитектуры предприятия по программе FEA» [35]. Этот критерий будет для Кэт основным индикатором того, что обе группы воспринимают методологию MEA всерьез, а деньги потрачены не зря.

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

Методология Gartner

До сих пор мы говорили о трех методологиях, объединенных под знаменем архитектуры предприятия. Последняя методология стоит несколько особняком. Она не является ни таксономией (как модель Захмана), ни процессом (как TOGAF), ни полной методологией (как FEA). Я бы назвал ее набором практических рекомендаций. Эта методология представляет собой набор рекомендаций по построению архитектуры предприятия от одной из наиболее известных в мире исследовательских и консалтинговых ИТ-организаций — компании Gartner.

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

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

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

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

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

Если бы вы были клиентом Gartner и захотели бы найти в ее библиотеке исследовательские материалы, посвященные архитектуре предприятия, вы бы нашли множество документов. Например, такими документами являются «Процесс создания архитектуры предприятия Gartner: развитие, 2005 г.» [36] и «Структура архитектуры предприятия Gartner: развитие, 2005 г.» [37]. Однако эти документы содержат мало описательной информации и, в любом случае, датированы концом 2005 г. Компания Gartner утверждает, что эти рекомендации носят вневременной характер, и продолжает их наращивать по мере необходимости. Текущая методология Gartner не фиксировалась вплоть до апреля 2006 г., после слияния компаний Gartner и Meta, о котором рассказывалось в разделе «История».

Лучшее из известных мне резюме практик Gartner звучит так:

архитектура — это глагол, а не существительное.

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

Компания Gartner уверена, что архитектура предприятия призвана объединить три группы профессионалов: владельцев бизнеса, ИТ-специалистов и специалистов по внедрению технологий. Если вам удалось объединить эти группы и сформировать у них единое представление о факторах, влияющих на ценность бизнеса, вы победили, если нет — проиграли. Успех оценивается чисто прагматически, например по доходности бизнеса, а не по количеству отмеченных элементов в матрице процесса.

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

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

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

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

Архитектура предприятия, согласно представлению Gartner, связана со стратегией, а не с технической реализацией. Она направлена на достижение цели. Два самых важных вопроса, которыми задается компания Gartner, — это куда организация стремится и как она туда попадет. Любое действие, не связанное напрямую с этими вопросами, считается неуместным. Аналитики Gartner любят употреблять следующую фразу: «Ровно столько архитектуры, сколько необходимо, и точно в срок».

Предположим, что Кэт (исполнительному директору MedAMore) понравилось все то, что она услышала. Как же применить методологию Gartner? При использовании методологий FEA, TOGAF и Захмана Кэт начинала работу с поиска квалифицированного консультанта. Что касается методологии Gartner, все гораздо проще: Кэт просто звонит в компанию Gartner.

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

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

• К 2010 г. компания MedAMore будет владеть аптеками не менее чем в 30 штатах в 8 географических регионах. Это будет достигнуто в основном путем приобретения региональных сетей.
• Компания MedAMore сможет ассимилировать новые региональные системы в течение 120 дней с момента приобретения.
• Компания MedAMore снизит закупочные цены на 10 % благодаря консолидации закупок в регионах в централизованную систему.
• Главный офис MedAMore сможет просматривать консолидированные отчеты о продажах и складских запасах по всем аптекам за любой период времени вплоть до вчерашнего дня.
• Компания MedAMore сможет сократить наличные запасы до уровня поставки в течение максимум пяти дней.
• Компания MedAMore сможет выставлять счета страховым компаниям к концу дня доставки рецепта пациенту.
• Пациенты смогут передавать рецепты от одного подразделения MedAMore в любое другое.
• Пациенты смогут запрашивать рецепты через веб-интерфейс и получать по электронной почте уведомление о возможности приобретения нужных лекарств.

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

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

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

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

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

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

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

Сравнение

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

Каждой методологии будет присвоена оценка по каждому из критериев. Оценки выставляются следующим образом:

• 1: Плохо работает в этой области
• 2: Недостаточно хорошо работает в этой области
• 3: Приемлемо работает в этой области
• 4: Очень хорошо работает в этой области

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

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

• Методология Захмана: 4
• TOGAF: 2
• FEA: 2
• Gartner: 1

Полнота процесса определяет, насколько полно в методологии представлен пошаговый процесс создания архитектуры предприятия. На этом практически полностью сосредоточена методология TOGAF, а именно представленная в ней методика разработки архитектуры (ADM). Оценки:

• Методология Захмана: 1
• TOGAF: 4
• FEA: 2
• Gartner: 3

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

• Методология Захмана: 1
• TOGAF: 3
• FEA: 4
• Gartner: 1

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

• Методология Захмана: 1
• TOGAF: 2
• FEA: 2
• Gartner: 4

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

• Методология Захмана: 1
• TOGAF: 1
• FEA: 3
• Gartner: 2

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

• Методология Захмана: 1
• TOGAF: 2
• FEA: 1
• Gartner: 4

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

• Методология Захмана: 1
• TOGAF: 2
• FEA: 3
• Gartner: 3

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

• Методология Захмана: 1
• TOGAF: 2
• FEA: 4
• Gartner: 3

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

• Методология Захмана: 1
• TOGAF: 2
• FEA: 4
• Gartner: 2

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

• Методология Захмана: 2
• TOGAF: 4
• FEA: 3
• Gartner: 1

Доступность информации определяет количество и качество бесплатных или относительно недорогих материалов по данной методологии. Оценки:

• Методология Захмана: 2
• TOGAF: 4
• FEA: 2
• Gartner: 1

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

• Методология Захмана: 1
• TOGAF: 3
• FEA: 1
• Gartner: 4

Критерии и оценки приведены на рис. 10.

Рис. 10. Критерии и оценки методологий

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

Как выбрать наиболее подходящую методологию? Я рекомендую использовать следующий подход:

• Пройдитесь по строкам (критериям) на рис. 10 и удалите те критерии, которые не важны для вашей организации.
• Добавьте строки (критерии), которые для вас важны, и оцените каждую из методологий по этим критериям.
• Если вы не согласны с моими оценками, выставьте свои.

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

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

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

Заключение

Эта статья представляет собой подробное введение в методологии построения архитектуры предприятия. История этого направления насчитывает 20 лет, однако оно продолжает развиваться — и весьма быстрыми темпами. Две из четырех ведущих методологий (Gartner и FEA) претерпели значительные изменения за последние два года.

Как было показано, эти методологии существенно отличаются друг от друга, как по целям, так и по подходам. У меня для вас две новости: хорошая и плохая. Плохая: многим организациям будет затруднительно выбрать одну методологию построения архитектуры предприятия. Как же выбрать из методологий, между которыми столь мало общего? Например, выбирать между методологией Захмана и TOGAF — все равно что выбирать между шпинатом и молотком.

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

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

Во многих организациях царит атмосфера недоверия между бизнес- и ИТ-специалистами. Ни одна методология построения архитектуры предприятия не позволит устранить этот разрыв, пока руководство не возьмет на себя обязательство о проведении реформ. Это обязательство должно быть принято на высшем уровне организации. Методология не позволяет решить проблемы с людьми; она может только дать структуру, в рамках которой эти проблемы можно решить.

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

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

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

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

Глоссарий

          методика разработки архитектуры (ADM) — процесс создания архитектуры предприятия, входящий в стандарт TOGAF.

          архитектура приложения — архитектура конкретного приложения.

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

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

          архитектурное описание — набор объектов (артефактов), предназначенных для документирования архитектуры.

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

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

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

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

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

          архитектура бизнеса — архитектура, связанная непосредственно с бизнес-процессами и ведением бизнеса.

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

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

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

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

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

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

          эталонная модель компонентов (CRM) — термин FEA, обозначающий ИТ-представление систем, поддерживающих бизнес.

          архитектура данных — архитектура принадлежащих предприятию данных (обычно хранящихся в базах данных).

          архитектор предприятий — архитектор, специализирующийся на построении архитектуры предприятия.

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

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

          FEA — см. архитектура федеральной организации (FEA).

          FEAF — см. структура архитектуры федеральной организации (FEAF).

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

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

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

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

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

          БКУ — см. Бюджетно-контрольное управление (БКУ).

          Gartner — исследовательская и консалтинговая ИТ-организация.

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

          Бюджетно-контрольное управление (БКУ) — подразделение правительства США, отслеживающее эффективность работы различных правительственных организаций.

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

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

          Административно-бюджетное управление — подразделение Исполнительного управления Президента США, выполняющее функцию президентского надзора за федеральными агентствами.

          The Open Group Architectural Framework — см . TOGAF (The Open Group Architectural Framework) 8.1.

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

          эталонная модель производительности (PRM) — термин FEA, обозначающий стандартные способы описания терминов, связанных с оценкой полезности.

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

          ROI — см. рентабельность инвестиций (ROI).

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

          информационная база стандартов (SIB) — термин TOGAF, обозначающий набор сведений о стандартах, в частности в области ПО с открытым исходным кодом.

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

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

          техническая эталонная модель (TRM) — часть стандарта TOGAF, эталонная модель, формирующая общий язык для различных компонентов ИТ-архитектуры. Этот термин также имеет сходное значение в методологии FEA.

          TOGAF (The Open Group Architectural Framework) 8.1 — методология построения архитектуры, разрабатываемая консорциумом The Open Group.

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

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

[01] Стандарт IEEE 1471-2000. Рекомендации IEEE по архитектурному описанию преимущественно программных систем.

[02] Захман Дж.А. «Структура архитектуры информационных систем». IBM Systems Journal, том 26, номер 3, 1987 г.

[03] Министерство обороны США. Базовая архитектура технического обеспечения для управления информацией (TAFIM), тома 1–8. Версия 2.0. Рестон, штат Вирджиния: Архитектурный центр Агентства по оборонным информационным системам, 1994 г.

[04] Акт Клингера — Коэна от 1996 г. (PL 107-347) (см. THOMAS [Библиотека Конгресса].)

[05] Совет директоров по информационным технологиям A04. Структура архитектуры федеральной организации, версия 1.1. Сентябрь 1999 г.

[06] Информационные технологии. Архитектура федеральной организации и архитектуры агентств продолжают развиваться. Заявление Бюджетно-контрольного управления для подкомитета по технологиям, информационной политике, межправительственным отношениям и переписи населения комитета по правительственным реформам, Палата представителей. 19 мая 2004 г.

[07] Информационные технологии. ФБР начало разрабатывать архитектуру предприятия, однако многое еще предстоит сделать. GAO-05-363. 9 сентября 2005 г.

[08] Модернизация бизнес-систем Министерства обороны США. Необходимо устранить давно существующие недостатки в разработке архитектуры предприятия. GAO-05-702. 22 июля 2005 г.

[09] Министерство национальной безопасности США. Прогресс есть, однако остаются трудности, связанные с управлением информационными технологиями. Заявление для подкомитетов Конгресса, Рэндольф К. Хайт, директор, проблемы ИТ-архитектуры и ИТ-систем. Бюджетно-контрольное управление. 29 марта 2006 г.

[10] Модернизация бизнеса. Есть прогресс по внедрению рекомендаций Бюджетно-контрольного управления в отношении интегрированной программы управления финансами НАСА. GAO-05-799R. 9 сентября 2005 г.

[11] «структура». Словарь американского культурного наследия. Четвертая редакция. Бостон, штат Массачусетс: Houghton Mifflin Company, 2006 г.

[12] «таксономия». Словарь американского культурного наследия. Четвертая редакция. Бостон, штат Массачусетс: Houghton Mifflin Company, 2006 г.

[13] Захман Дж.А. «Структура архитектуры предприятия: основы, описание и применение». Институт Захмана по развитию структуры (ZIFA). Код документа: 810-231-0531

[14] О'Рурк, Кэрол, Нил Фишман и Уоррен Селкоу. Архитектура предприятия на основе структуры Захмана. Бостон, штат Массачусетс: Технология курса, 2003 г. ISBN: 0-619-06446-3

[15] Интервью с Джоном Захманом, Роджер Сешнс, главный редактор журнала Перспективы Международной ассоциации архитекторов программного обеспечения, выпуск 6.

[16] Захман Дж.А. «Структура архитектуры информационных систем». IBM Systems Journal, том 26, номер 3, 1987 г.

[17] Захман Дж.А. и Сова Дж.Ф. «Расширение и формализация структуры для архитектуры информационных систем». IBM Systems Journal, том 31, номер 3, 1992 г.

[18] Захман Дж.А. «Структура архитектуры информационных систем». IBM Systems Journal, том 26, номер 3, 1987 г.

[19] www.opengroup.org

[20] www.opengroup.org/togaf

[21] Перкс, Кол и Тони Беверидж. Руководство по ИТ-архитектуре предприятия. Нью-Йорк, штат Нью-Йорк: Springer, 2003. ISBN: 0-387-95132-6

[22] www.opengroup.org/togaf/cert

[23] Перкс, Кол и Тони Беверидж. Руководство по ИТ-архитектуре предприятия. Нью-Йорк, штат Нью-Йорк: Springer, 2003. ISBN: 0-387-95132-6

[24] TOGAF, версия 8.1.1.

[25] «Документация по эталонным моделям FEA, версия 2.1», декабрь 2006 г., опубликовано FEAPMO, Административно-бюджетное управление.

[26] Практическое руководство по FEA совета директоров по информационным технологиям, версия 1.0, февраль 2001 г.

[27] «Практическое руководство по FEA», декабрь 2006 г., опубликовано FEAPMO, Административно-бюджетное управление.

[28] «Документация по эталонным моделям FEA, версия 2.1», декабрь 2006 г., опубликовано FEAPMO, Административно-бюджетное управление.

[29] Там же.

[30] Там же.

[31] Там же.

[32] «Эталонная модель данных, версия 2.0», ноябрь 2005 г., опубликовано FEAPMO, Административно-бюджетное управление.

[33] «Документация по эталонным моделям FEA, версия 2.1», декабрь 2006 г., опубликовано FEAPMO, Административно-бюджетное управление.

[34] «Практическое руководство по FEA», декабрь 2006 г., опубликовано FEAPMO, Административно-бюджетное управление.

[35] Структура оценки архитектуры предприятия по программе FEA 2.1, декабрь 2006 г.

[35] Там же.

[36] Биттлер, Скотт Р. и Грег Крейцман. «Процесс создания архитектуры предприятия Gartner: развитие, 2005 г.». 21 октября 2005 г. Код Gartner: G00130849

[37] Джеймс, Грета А., Роберт А. Хэндлер, Энн Лапкин и Николас Галл. «Структура архитектуры предприятия Gartner: развитие, 2005 г.». 25 октября 2005 г. Код Gartner: G00130855

 Об авторе

Роджер Сешнс является техническим директором в компании ObjectWatch. Издаваемый им Бюллетень ObjectWatch публикуется вот уже 13 лет. Роджер Сешнс — автор шести книг, в том числе Программные крепости: моделирование архитектуры предприятия (издательство Addison-Wesley, 2003 г.), и множества статей. Он входит в совет директоров Международной ассоциации архитекторов программного обеспечения (IASA), является главным редактором журнала «Перспективы Международной ассоциации архитекторов программного обеспечения», а также экспертом со статусом MVP в области архитектуры предприятия. Роджер владеет рядом патентов как на программное обеспечение, так и на процессы разработки архитектуры предприятия. Он выступал с докладами более чем на 100 конференциях по всему миру, посвященных широкому спектру вопросов в сфере архитектуры предприятия. Дополнительные сведения о Роджере Сешнсе и компании ObjectWatch см. по адресуwww.objectwatch.com.