Этап 1: Разработка Общего видения архитектуры

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

Основными элементами Общего видения являются:

· описание технологических тенденций, важных для предприятия;

· идентификация бизнес-требований и стратегий;

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

· идентификация требований к архитектуре предприятия в целом.

Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей

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

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

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

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

Этап 3: Разработка Плана реализации

Этап 3 включает в себя следующие два шага:

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

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

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

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

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

10.3.2. Направления разработки архитектуры: " сверху-вниз" или " снизу-вверх"

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

· Подход " сверху-вниз" предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры " как есть". Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF).

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

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

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

Как всегда, в каждом варианте есть свои плюсы и минусы, которые кратко просуммированы в табл. 10.1.

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

Архитектура предприятия как планирование города

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

Независимо от того, отвечаете ли вы за проект архитектуры предприятия в целом, или за внедрение отдельной CRM-системы, или за проект консолидации серверов – многому можно научиться, анализируя то, как современные города приспосабливаются под потребности своих жителей и потребности бизнеса. (Альтернативный взгляд: мы, как жители, приспосабливаемся под возможности города так же, как иногда приходится приспосабливаться под устаревший интерфейс прикладных систем). Заметим, что эта аналогия не оканчивается прямыми сравнениями типа город – совокупность ИТ-систем предприятия, здания – прикладные системы, городская инфраструктура – ИТ-инфраструктура. Много аналогий прослеживается в процессах планирования и развития города и планирования и развития ИТ-архитектуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Четвертое: важность стабильной инфраструктуры. Инфраструктура ИТ должна обслуживать текущие потребности и в какой-то степени предвосхищать будущие потребности в системах.

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

Шестой вывод заключается в максимальном использовании того, что есть. Любой город старается по максимуму использовать ресурсы существующей инфраструктуры, прежде чем запускать новые дорогостоящие проекты ее обновления. Точно также большое количество имеющихся на предприятии унаследованных систем – это, скорее, актив, чем пассив, и его можно и нужно эффективно использовать. Функционал этих систем можно, в частности, " открыть" для интеграции с новыми прикладными системами, используя адаптеры и технологии web-сервисов.

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