Построение архитектуры предприятия
Не надо питать иллюзий насчет того, что работа архитектора заканчивает-ся строительством видения великолепной архитектуры предприятия. Архитек-тура информационных технологий - это только на 10% видение, а на 90%- кропотливая работа по реализации.
Реализация архитектуры предприятия не является проектом в строгом смысле этого слова. Дело в том, что за фазой разработки неизбежно должна по-следовать деятельность по поддержанию и постоянному развитию архитектуры предприятия, а это более удобно описывать в рамках процессной модели. Одна-ко на практике часто встречаются следующие два случая, когда целесообразно организовать выполнение специального архитектурного проекта.
С учетом существующего реального состояния дел большинство организаций либо не имеют формализованной определенной архи-тектуры, либо эти определения неполны и недостаточно четко связаны с требова-ниями бизнеса. В таких случаях имеет смысл организовать работу в рамках специ-ального проекта с определенными сроками и результатами, основной целью кото-рого будет являться создание первоначального описания архитектуры организа-ции и создание механизмов для ее последующего поддержания и развития.
Первоочередными задачами такого проекта являются:
· организация необходимых структур с привлечением руководства предпри-ятия, бизнес-подразделений и планирование работ;
· понимание стратегии развития бизнеса организации;
· формирование общих для бизнеса и ИТ требований к целевой архитектуре;
· разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разра-ботка архитектуры отдельных доменов (предметных областей или частных архитектур).
Для многих организаций отправной точкой в создании общей архитектуры предприятия может стать существующая ИТ-архитектура.
Другим возможным вариантом выделения такой деятельности в отдельный проект может явиться потребность в проведении эволюционного скачка в архи-тектуре. Например, открытие нового бизнес-направления или внедрение новой ERR-системы потребует значительных изменений в вычислительной и сетевой инфраструктуре, реорганизации ИТ-службы и т.п. Возможностей существующей группы поддержки архитектурного процесса окажется недостаточна для реше-ния таких задач, и потребуется привлечение дополнительных внутренних и внешних ресурсов, что опять-таки удобнее выполнять в рамках четка опреде-ленного проекта.
Какую бы архитектурную методику вы ни выбрали, при всех расхождениях в деталях проект работы над созданием архитектуры обычно включает решение следующих задач:
· Определение и обоснование цели - ответы на вопросы Почему? и Что?
· Выполнение ряда шагов, связанных с инициацией процесса разработки ар-хитектуры (см. ниже).
· Определение существующего состояния архитектуры («as-is») для каждой выбранной области (домена) - отправная точка ответа на вопрос где?
· Определение целевой архитектуры - конечная точка ответа на вопрос где ?
· Анализ расхождений между текущим и желаемым состоянием.
· Разработка плана перехода - ответы на вопросы Когда? и Как?
· Подтверждение (проверка) достижимости - можно ли на самом деле до-стичь конечного состояния из данного начального состояния с учетом су-ществующих ограничений?
· Выполнение намеченного плана.
Здесь стоит особенно отметить важность усилий для решения третьей за-дачи. С одной стороны, формирование целостного описания существующей ар-хитектуры может потребовать проведения настоящих «археологических раско-пок» в ранее существовавшей документации, изучения существующих преданий и посвящения в «тайные знания» о годами работающих системах. С другой сто-роны, здесь важно определить набор целевых метрик (надежность, стоимость эксплуатации и т.п.) и их начальных значений - иначе потом будет очень труд-но объективно оценить, достигнуты ли цели проекта.
Начальные действия по инициации самого проекта разработки архитекту-ры включают следующие шаги:
· определение «устава» (основных правил) и границ проекта;
· бизнес-обоснование реализации проекта разработки архитектуры пред-приятия;
· получение поддержки высшего руководства;
· определение состава рабочей группы (организационная структура и уча-стники);
· проведение рабочей встречи, посвященной началу проекта разработки архитектуры и определения других высокоуровневых документов, которые необходимы для более детальных работ по разработке архитектуры;
· создание рабочих групп, которые будут разрабатывать различные фокусные области или домены в рамках общего проекта (например, бизнес-архитек-тура, архитектура информации, прикладных систем, инфраструктуры).
Высокоуровневые документы, которые должны быть результатом первооче-редных шагов, являются ключевыми для дальнейшей, более детальной проработ-ки архитектуры. Они создают некоторый культурный контекст всех усилий и обес-печивают связь работы по созданию архитектуры с бизнес-стратегиями и приори-тетами предприятия. Список этих высокоуровневых документов может включать:
· бизнес-факторы, влияющие на деятельность предприятия;
· внутренние и внешние технологические факторы;
· формулировку общего видения Архитектуры предприятия;
· высокоуровневые принципы.
Важной составляющей всего проекта является создание структур управле-ния и контроля архитектурного процесса (governance), который должен обеспе-чить то, что сообщество специалистов на практике использует результаты этих работ; вторая серьезная задача - обеспечение связей процесса разработки ар-хитектуры с процессами бизнес-планирования и выработки ИТ-стратегии.
Общая блок-схема процесса в итоге выглядит, как показано на рис. 1.7.
Рис. 1.7. Общая схема построения архитектуры предприятия
В принципе, существуют три возможных подхода к организации процесса разработки архитектуры:
· Традиционный обычный подход. Он требует существенных начальных за-трат времени и ресурсов для достижения первых ощутимых результатов. В этом подходе в первую очередь разрабатывается регламент для будущего описания архитектуры. Затем должно быть определено текущее базовое состояние архитектуры и только после этого представлена целевая архи-тектура. Лишь когда все зги действия закончены, начинается детальное проектирование и разработка необходимой Архитектуры предприятия.
· Сегментный подход. Суть этого подхода состоит в постепенной поступа-тельной разработке сегментов архитектуры в рамках общей структуры, описывающей принципы Архитектуры ИТ. Этот подход сосредоточивается на главных бизнес-сферах и областях архитектуры и имеет больше шансов на успех, поскольку усилия ограничены пределами общих выполняемых функций, а также сфер специфической деятельности предприятия.
· Подход статус-кво или «оставить все как есть». Результатом этого будут провалы в попытках наладить информационный обмен, невозможность реакции на быстроменяющееся окружение. Этот подход также означает постоянную переделку бизнес-функций, снижение производительности, потерянные или упущенные возможности.
Традиционный, обычный подход при всей кажущейся его правильности связан с риском «паралича анализа», который особенно неконструктивен в рос-сийских условиях переходной экономики и процессов реформирования госу-дарства. Чтобы сократить возможные риски неудач, обеспечить снижение на-чальных затрат и добиться быстрой отдачи от проекта разработки Архитектуры ИТ, рекомендуется второй, т.е. сегментный подход.
Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования Ар-хитектуры предприятия, которая называется ЕАР (Entrerprise Architecture Planning - Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архи-тектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции). Эти 7 компонент, условно изображенных на рис. 1.8 в виде «свадебного торта», обозначают смещение фокуса приложе-ния сил на каждом из шагов.
Рис. 1.8. Методика Спивака
Подход Спивака уже помог очень многим компаниям и государственным ведомствам в организации процесса моделирования, стратегического бизнес-планирования, реорганизации деловых процессов, проектировании различных систем, выработки стандартов на данные, управления проектами. В частности, этой методикой пользовались такие организации, как Federal Express, Министер-ство энергетики США, Штаб Военно-воздушных сил США и другие. Например, в Министерстве энергетики США основная фаза процесса разработки архитектуры («проект») заняла примерно б месяцев.
Методика ЕАР обеспечивает высокоуровневый взгляд на предприятие с точки зрения его бизнес-функций и требований в области информации. Это ин-струмент планирования, а не детального проектирования архитектуры. Резуль-таты планирования используются в качестве основы для интегрированной раз-работки прикладных систем и технологий, которые обеспечивают потребности бизнеса. Отличительными характеристиками этого подхода к планированию ар-хитектуры являются следующие:
· в основе - потребности бизнеса, а не технологические факторы;
· основное внимание сосредоточено более на данных и потребностях в ин-формации, чем на процессах;
· ответственность за процесс в большей степени несут представители биз-нес-подразделений,чем специалисты по ИТ.
Если «наложить» методику ЕАР Спивака на модель архитектуры Захмана (см. пункт 2.2),то можно сказать, что методика ЕАР является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. зто перспекти-вы, соответствующие представлениям об архитектуре бизнес-руководителей: «планировщика» и «владельца». Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками методики Спивака.
Это замечание ничуть не умаляет достоинств методики Спивака, но ниже мы рассмотрим более подробно и остальные элементы архитектурного процесса.
Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является системати-ческое и рекурсивное применение таких принципов, как:
· декомпозиция на различные представления архитектуры (предметные об-ласти): область прикладных систем, технологическая архитектура и т.д.;
· различные уровни детализации и абстракции для описания каждой из этих областей.
Схема процесса разработки в самом общем виде представлена на рис. 1.9. Об-ратим внимание на то, что фактически здесь идет речь о параллельных активностях по определению как целевой архитектуры, так и стратегии ее достижения. 
Рис. 1.9. Общая схема процесса разработки архитектуры
Эта схема состоит из следующих шагов:
· Общим фоном для этого процесса является мониторинг существующих тен-денций в области деятельности организации и тенденций в области разви-тия информационных технологий.
· Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования биз-неса и технологии на текущем этапе и на перспективу, которые задают тре-бования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса.
· На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ.
· Принимаются общие для организации стандарты и понятия о том, что такое архитектура предприятия: принципы, общие методы описания архитекту-ры и ее разделы, стандарты, конкретные продукты и технологии.
Параллельно с этими процессами выполняется анализ на «системном уровне»: аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внед-рения технологий и приложений.
Результаты вышеперечисленных этапов являются основой для выполнения «GAP-анализа», т.е. выявления расхождений и различий между существу-ющей ИТ-инфраструктурой и желаемой архитектурой предприятия. Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информацион-ных технологий (перечень критических процессов, подлежащих автомати-зации в первую очередь и т. д.), обсуждается план детального анализа.
После этого начинается фаза реорганизации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия.
С практической точки зрения, реализация инициативы в области разработ-ки архитектуры предприятия разделяется на несколько фаз или этапов. На каж-дом этапе готовится совершенно определенный набор документов и иных мате-риалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю иници-ативу разработки архитектуры в целом.
Основой работы на этих этапах является эволюционный, итеративный про-цесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития ((GAP-анализ), который обеспечит синхрониза-цию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях.
Архитектура, в результате, является одновременно как постоянным организационным процессом, так и результатом,который мате-риализуется в форме моделей и документов, описывающих существующее и бу-дущее состояние архитектуры.
Разработка архитектуры является сложным процессом, который обеспечи-вает движение от описания общего положения с имеющимися информационны-ми системами и инфраструктурой к практической реализации информационных систем, их эксплуатации и оценке результатов. Процесс носит нелинейный, цик-лический характер, и было бы ошибкой считать, что разработка архитектуры- это одноразовая кампания, которая обеспечивает простое перемещение инфор-мационных систем предприятия из состояния «А» в состояние «Б». Архитектура - это постоянный процесс, который нацелен на обеспечение постоянных улуч-шений в той области, которая связана с отдачей от использования информаци-онных технологий для реализации бизнес-функций предприятия и его соответ-ствующих подразделений.
Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем пред-приятия. Это два взаимосвязанных процесса, которые, однако, имеют различные «скоростные характеристики». Архитектурный процесс по своей природе является концептуальным, имеетдлительный временной горизонт, в та время как реали-зация систем ориентирована на внедрение конкретных решений и реализацию проектов с более коротким временным горизонтом.
Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разра-ботки архитектуры.
Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям МЕТА Group. Харак-терными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, да-же в случае выбора какой-то другой методики, скорее всего придется созда-вать аналоги этих документов. Каждая итерация включает:
· Этап 1: Описание или уточнение Общего видения (видение общих требова-ний к архитектуре).
· Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура инфор-мации, архитектура приложений, технологическая архитектура и пр.
· Этап 3: Разработка или уточнение Плана реализации.
При первой итерации этого процесса разрабатываются только те пред-ставления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Напри-мер, если будет принято решение, что наиболее острой проблемой является ин-вентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем,должна разрабатываться в приоритетном порядке.
После завершения всех трех этапов первой итерации рабочая группа, от-вечающая за разработку архитектуры, продолжает разработку архитектур ос-тальных доменов (предметных областей), не проработанных ранее, с учетом на-копленного опыта и информации на предыдущих итерациях.
Итого пересматривая состав этапов можно заметить следующее:
Этап 1: Разработка Общего видения архитектуры
Общее видение обеспечивает единое понимание проблемы между функци-ональным (бизнес-) руководством и людьми, отвечающими за информационн--коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры.
Основными элементами Общего видения являются:
· описание технологических тенденций, важных для предприятия;
· идентификация бизнес-требований и стратегий;
· идентификация основных требований к информации и технологиям, кото-рые важны с точки зрения реализации бизнес-стратегий;
· идентификация требований к Архитектуре предприятия в целом.
Мы уже отмечали, что многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы "облако неопределенности" между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач .
Процесс транслирования этих целей в конкретные ИТ-системы часто носит очень неразвитый характер и ограничивается ежегодным бюджетным процессом, участие в котором представителей бизнеса и ИТ является основным способом общения и взаимодействия.
Рис.
3.1.
"Облако неопределенности" между целями организации и информационными технологиями
Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация , прикладные системы, технологическая инфраструктура .
Бизнес-модели описывают стратегию организации, структуры управления, требования, ограничения и правила, а также основные бизнес-процессы , включая взаимосвязи и зависимости между ними. Т.е. бизнес- архитектура описывает на уровне предприятия в целом то, как реализуются основные функции организации, включая организационные и функциональные структуры, роли и ответственности.
Архитектура информации определяет ключевые активы , связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая расположение, время, типы файлов и баз данных и других информационных хранилищ.
Архитектура прикладных систем описывает те системы, которые и обеспечивают необходимый функционал для реализации логики бизнес-процессов организации.
С точки зрения технологической архитектуры, важные модели включают описание ИТ-сервисов, которые требуются для реализации перечисленных выше трех других областей архитектуры. Причем логические модели ИТ-сервисов построены в абстрактной, технологически независимой форме и оставляют свободу для оптимального выбора конкретных технологий. Но, в конце концов, архитектура предприятия завершается физическими моделями, которые определяются технологиями, аппаратными и программными платформами, выбранными для реализации ИТ-сервисов.
Термин "ИТ- архитектура " может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл одного и того же термина может быть разным. Каждый из нас, на самом деле, может достаточно быстро сформулировать интуитивное определение , которое после анализа окажется вполне применимым. Известных формальных определений архитектуры существует несколько сотен. Для этого достаточно зайти на сайт Института Проектирования Программного Обеспечения Карнеги-Меллона ( SEI – Carnegie Mellon Software Engeneering Institute) www.sei.cmu.edu . Одно из самых простых (словарь Уэбстера) заключается в том, что ИТ- архитектура – это "способ, который используется для организации и интеграции компонент компьютерной системы".
Более изощренное определение в хорошо знакомом программистам стиле заключается в том, что " Архитектура системы состоит из нескольких компонент , внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент ". Такое рекурсивное определение удобно тем, что является достаточно общим, применимым практически к любой системе, а не обязательно только к системе, использующей информационные технологии , и при этом позволяет ограничить степень детализации на нужном уровне. Отметим, что упоминание внутренних компонент специально перенесено в конец определения – для отражения того факта, что "хорошая" архитектура позволяет обеспечить повторное использование или модернизацию/замену таких внутренних компонент без изменения внешней охватывающей системы. Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу – облегчить ее восприятие человеком.
Рис. 3.2.
Хорошо известно, что оптимальным в этом смысле числом элементов на отдельном уровне любой схемы абстракции или в каком-либо списке является всего 7 плюс или минус 2 объекта. Именно поэтому, как мы увидим ниже, большинство подходов к описанию архитектуры включает в себя ее разбиение на предметные области (или представления), общее количество которых как раз и находится в этом диапазоне. Примерами таких предметных областей являются архитектура прикладных систем, архитектура данных, технологическая архитектура и т.д. Старый, как мир, принцип "разделяй и властвуй" как нельзя лучше подходит для того, чтобы справляться с объективной сложностью корпоративных информационных систем. При этом такое разбиение позволяет рабочим группам, специализирующимся на различных предметных областях, работать параллельно, что делает проблему осознаваемой с интеллектуальной точки зрения.
Прежде чем давать, наконец, полное определение архитектуры ИТ, сделаем еще одно предварительное замечание. В соответствии с тезисом, сформулированным Giga
Число изменений во внешней среде нарастает с высокой скоростью, и поэтому требования к адаптивности компаний повышаются год от года. В статье рассматриваются основные принципы управления архитектурой предприятия, наиболее известные методы в данной области и преимущества их применения.
Изменения и адаптивность компании
Число изменений во внешней среде нарастает с безумной скоростью, и поэтому требования к адаптивности компаний возрастают год от года. По различным аналитическим исследованиям топ-менеджеры большинства международных компаний больше всего напуганы тем фактом, что их компании не успевают адаптироваться к происходящим изменениям, при этом тренд в этой области отрицательный Во многих случаях основная проблема в обеспечении адаптивности компании – это согласование и контроль требуемых изменений в рамках всей организации. При изменении целей, меняется стратегия, что в свою очередь требует изменений в бизнес-процессах и приоритетах проектов, а также в организационной структуре.
Все это косвенным образом влияет на знания и полномочия внутри компании, а это в свою очередь может привести к изменениям в информационных потоках, которые в свою очередь потребуют изменений в существующих информационных системах. В качестве решения вышеозначенной проблемы, необходимо анализировать все элементы предприятия в целом, при этом такая совокупность элементов называется архитектурой предприятия. Управление архитектурой предприятия (Enterprise Architecture), создает основу для синхронизации всех вышеперечисленных объектов внутри организации, и в тоже время запускает цикл их непрерывного изменения для целей оптимизации бизнеса.
«Архитектура предприятия устанавливает путь к достижению миссии организации благодаря оптимальному функционированию ее ключевых бизнес-процессов внутри эффективного ИТ- окружения.” Jaab Schekkerman, Institute For Enterprise Architecture Development (IFEAD).
Прослеживаемость изменений и согласованность всех элементов архитектуры внутри компании увеличивает ее адаптивность, что в настоящее время является наиболее важным фактором в конкурентной борьбе. При этом, фактором сдерживающим изменения, часто могут стать информационные системы, что требует особого внимания при синхронизации элементов бизнес -архитектуры и ИТ-архитектуры.
Для используется стандартный цикл, состоящий из следующих шагов: описание существующей архитектуры, проектирование целевого состояния архитектуры, формирование плана перехода от существующей к целевой архитектуре. При этом на первом шаге основной сложностью является определение того, какие элементы архитектуры и в каком объеме нужно описывать.
С одной стороны детальность создаваемого описания означает более глубокую проработку отдельного, а с другой стороны излишние появляются излишние трудозатраты как на создание самого описания, так и на поддержку его в актуальном состоянии. Как говорится «лучшее враг хорошего», и поэтому слишком полное и подробное описание элементов архитектуры не приносит пользы. Именно поэтому «в начале пути» так важно определение ключевых элементов архитектуры предприятия из всех возможных и концентрация именно на их описании и анализе. Практика показывает, что первое рассогласование в архитектуре предприятия , как правило, возникает между целями, бизнес-процессами и организационной структурой. Во многих случаях множество целей не поддержаны необходимыми ресурсами и бизнес-процессами.
Поэтому уже на этом этапе анализа архитектуры предприятия можно определить план работ по оптимизации деятельности компании в этой части. Если проанализировать существующие в компании информационные технологии, то они также часто несогласованны с существующими, а тем более целевыми бизнес-процессами. И здесь тоже появляется обширное поле для оптимизации деятельности. Помимо несогласованности между ключевыми элементами архитектуры предприятия часто можно увидеть проблемы и внутри отдельного элемента, в первую очередь это дублирование, а также организационные и информационные разрывы и т.д.
Однако не только числом изменений и требованием к адаптивности компании вызвано столь серьезное внимание к вопросам управления архитектурой . Сложность технологических систем возрастает, что означает снижение их надежности. И здесь формализация архитектуры предприятия становится базой для обеспечения процедур управления операционными рисками и в компании. Ведь если основные элементы архитектуры предприятия формализованы, то определить риски и проанализировать эффективность процедур контроля уже не представляет особой сложности. Именно поэтому наиболее критично управление архитектурой в крупных компаниях, использующих сложные технологии, которые сопряжены с множеством операционных и технологических рисков.
Управление архитектурой предприятия
Сейчас можно отметить, что российские компании начали использовать архитектурный подход при совершенствовании своей деятельности и при внедрении ИТ- приложений, хотя нам еще далеко до таких лидеров в этой области как США. Архитектура предприятия должна стать основой для определения структуры компании (цели, ключевые показатели результативности, бизнес-процессы, организационная структура и т.д.), информации необходимой для ведения бизнеса (данные, документы, информация и т.д.) и информационных технологий используемых для поддержки бизнес-процессов.
Фактически можно выделить бизнес-архитектуру и ИТ- архитектуру компании. Согласованность всех элементов архитектуры между собой позволит «навести порядок», при этом для обеспечения адаптивности необходимо не только построение архитектуры, но и создание процесса управления изменениями в целях обеспечения соответствия существующей архитектуры предприятия изменяющейся внешней среде.
Для решения задач построения архитектуры предприятия создано множество методологий (Frameworks):
Модель Захмана (Framework for Information Systems Architecture) — методика описания архитектуры информационных систем;
DoDAF – Department of Defense Architecture Framework – методика описания архитектуры Министерства обороны США, ранее известная под названием C4ISR AF;
FEAF – Federal Enterprise Architecture Framework — Федеральная Архитектура Государственных организаций США;
TEAF - Treasury Enterprise Architecture Framework — методика описания архитектуры казначейства США;
TOGAF – The Open Group Architecture Framework — методика описания архитектуры разработанная Open Group;
NASCIO - National Association of State Chief Information Officers – методика, разработанная Национальной ассоциацией CIO США;
NATO Architecture Framework — методика описания архитектуры НАТО;
Enterprise Architecture Desk Reference — документ компании META Group;
Самой первой считается модель Захмана, созданная в 1987 году, на ее основе были разработаны многие существующие модели и методики в области управления архитектурой предприятия. Все эти наработки в той или иной степени задают классификацию основных элементов архитектуры и единые принципы для их описания во взаимной увязке друг с другом, а также используемые правила и модели, которые применяются для формализации элементов архитектуры на разных уровнях детализации. В качестве примера одной из методологий можно привести элементы архитектуры TOGAF, которая предложена некоммерческим объединением Open Group, в которое входит ряд ведущих производителей в области. При этом нужно отметить, что данная архитектура не является эталонной моделью, а скорее является методологией разработки архитектуры предприятия.
От бизнес- архитектуре к архитектуре ИТ
Согласование требований бизнеса и возможностей информационных технологий является одним из ключевых преимуществ от управления архитектурой предприятия . Сейчас развитие современного бизнеса трудно представить без применения информационных технологий, ведь результативность существующих бизнес-процессов зависит от качества их информационной поддержки. Часто в крупных компаниях каждое подразделение использует в работе «собственные» информационные системы, начиная от электронных таблиц и заканчивая «тяжелыми» ERP – системами. Однако во многих случаях отсутствует единый взгляд на использование информационных систем в рамках «сквозного» процесса компании.
При этом если автоматизацией бизнеса заниматься несистемно и без применения архитектурных подходов, то в скором времени компания столкнется с серьезными проблемами, связанными с использованием информационных технологий и их соответствию требованиям бизнеса. В начале развития компании использование множества различных информационных систем, иногда дублирующих друг друга, кажется не очень страшным. Однако, по мере увеличения размера компании «зоопарк» информационных систем увеличивается, и в какой-то момент, при попытке сделать требуемые изменение в бизнес-процессе, затрагивающем множество подразделений и информационных систем, придется изменять большое число различных ИТ- решений, что потребует серьезных ресурсов. К сожалению, эта проблема возникает от пренебрежения архитектурным подходом при планировании развития информационных технологий. Еще одной проблемой большинства компаний является отсутствие качественного документирования существующих ИТ — решений. Внедренные информационные системы должны быть документированы на требуемом уровне, иначе компания через некоторое время столкнется с «черным ящиком», работа которого непонятна никому.
В российской практике существует множество случаев, когда компании отказывались от внедренной информационной системы, из-за некачественного документирования и начинали внедрение новой системы. Это происходит по причине невозможности внесения изменений в такую систему, что делает ее неудобной для бизнеса. Таким образом, управление архитектурой предприятия может решить основную проблему автоматизации бизнес-процессов сократить «разрыв» между существующими бизнес-процессами и средствами их автоматизации. В большинстве случаев причиной такого разрыва является неформализованность бизнес-процессов и требований к информационной системе, а также сложность внесения изменений в существующие ИТ-решения. И если не предпринимать специальных действий, то этот «разрыв» будет только увеличиваться со временем, пока не произойдет отказ бизнеса от использования информационной системы, а значит потери сделанных инвестиций в развитие информационных технологий.
В настоящее время на ИТ- рынке окончилась «ERP-эйфория» – вера в возможность полной автоматизации бизнеса одной монолитной информационной системой. Множество компаний, вложив миллионы долларов в автоматизацию, так и не получили требуемых преимуществ. И теперь понятно, что «зоопарк» информационных систем в компании неизбежен. Именно поэтому сегодня необходимо описывать и анализировать существующую ИТ- архитектуру компании и синхронизировать ее с бизнес- архитектурой, а не надеяться на полномасштабную автоматизацию с помощью одной информационной системой. Сложность взаимодействия бизнеса и ИТ усугубляется масштабностью бизнеса в глобальных холдингах, а также наследованием бизнес-процессов и информационных систем в результате слияний и поглощений. При увеличении уровня использования информационных технологий, растет зависимость бизнеса от качества и надежности поддерживающих его информационных систем и ИТ- инфраструктуры, что в свою очередь требует четкости и прозрачности взаимосвязи бизнес-процессов с ИТ- архитектурой и ИТ- инфраструктурой.
Именно поэтому сейчас основными требованиями к существующей ИТ -архитектуре и ИТ – инфраструктуре компании является надежность поддержки бизнес-процессов, а также гибкость существующих информационных систем, заключающаяся в способности быстрой адаптации к изменяющимся бизнес- процессам. Все эти требования можно выполнить, только если начать системно заниматься автоматизацией бизнес-процессов, уделяя внимание вопросам построения как ИТ – архитектуры, так и архитектуры бизнеса в целом, что делает применение архитектурных подходов строго необходимым для обеспечения выживаемости бизнеса в сегодняшних условиях.
Ключевые элементы архитектуры предприятия
Несмотря на присутствие большого числа методологий в области создания и управления архитектурой предприятия , на практике большинство компаний ограничиваются следующими элементами архитектуры предприятия : цели бизнеса; организационная структура; ключевые показатели результативности; бизнес-процессы; портфель проектов; документы; информационные системы; знания персонала. Это тот необходимый минимум, который позволяет согласовать основные элементы архитектуры между собой. При этом если цели, показатели, организационная структура и бизнес-процессы часто уже как-то взаимосвязаны между собой, то между процессами и информационными системами такой взаимосвязи часто нет. Поэтому, одной из первоочередных задач, для многих компаний является переход от моделей и регламентов бизнес-архитектуры к вопросам определения требований к информационным технологиям и построения соответствующей им ИТ- архитектуры.
Информационный разрыв вызван передачей информации от бизнес-аналитиков к ИТ – специалистам, и в этот момент формализация таких элементов архитектуры, как требования, ИТ- функции, транзакции, структуры данных вместе с бизнес-процессами позволяет этот разрыв сократить. На этом этапе наиболее правильно использовать рекомендации, содержащиеся в вышеозначенных методологиях описания архитектуры предприятия, например в TOGAF. Таким образом для устранения «информационного разрыва» между бизнесом и ИТ необходимо расширять описание существующей архитектуры предприятия и, в частности архитектуру бизнеса, в направлении ИТ- архитектуры с учетом единства используемой методологии описания как для бизнес- аналитиков, так и для ИТ –специалистов. При таком переход от описания архитектуры бизнес-процессов к описанию ИТ- архитектуры необходимо формализовать несколько дополнительных элементов архитектуры. В первую очередь необходимо описать архитектуру данных, которая строится на основании той информации и документов, которые используются в бизнес-процессах, после чего необходимо сформировать архитектуру приложений и ИТ- инфраструктуру.
Переход от бизнес- архитектуры к ИТ — архитектуре (приложения, информация, инфраструктура)
Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи можно использовать стандартную методологию описания данных — модель «сущность-связь» (Entity-Relationship Model – ERM), в рамках которой можно четко структурировать всю информацию.
Следующим этапом формализации ИТ-архитектуры является переход от архитектуры бизнес-процессов и архитектуры данных к созданию архитектуры приложений. На этом этапе необходимо определить классы информационных систем, необходимых для автоматизации, после чего определить необходимые модули для каждой информационной системы. Здесь, основой для проектирования архитектуры приложений и ее синхронизации с бизнес -архитектурой является карта процессов (обобщенное представление всех бизнес-процессов предприятия). На модели архитектуры приложений располагаются основные типы информационных систем, которые далее детализируются на модели модулей информационных систем, и далее до уровня отдельных экранных форм — транзакций. Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнеса и ИТ являются требования к информационной системе.
Фактически модели требований — это целевой функционал ИТ — решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 году TeleManagement Forum, и содержит следующие модели: ·
информационная модель телекоммуникационного предприятия (Enterprise-wide information framework Shared Information and Data Model — SID);
структура приложений телекоммуникационной компании (Applications framework – Telecom Applications Map — TAM).
Заключение
В заключение можно отметить, что основной задачей при управлении архитектурой предприятия является синхронизация всех элементов архитектуры между собой. При этом одной из ключевых задач является взаимосвязь бизнес- архитектуры и архитектуры ИТ с одной стороны через документирование, совершенствование и стандартизацию бизнес-процессов, а с другой через описание элементов ИТ- архитектуры на логическом уровне, во взаимосвязи с бизнес-процессами. При этом концентрация в управлении архитектурой предприятия должна происходить лишь на ключевых элементах, что позволит получить максимальный результат с минимальными ресурсами.
Распыление ресурсов на описание всех элементов архитектуры часто дает отрицательный результат с точки зрения бизнеса, поскольку отодвигает горизонт решения существующих проблем на очень длительный период. Цели, показатели, процессы, проекты, организационная структура, документы, данные, приложения – вот тот необходимый минимум, который позволит начать внедрение архитектурных подходов в деятельность компании. В части глубины описания рекомендация может быть одна – если есть возможность обойтись существующим уровнем описания – нет смысла создавать еще один.
Такой подход позволит сэкономить много ресурсов, при этом получив значимый для бизнеса результат. В части ИТ-архитектуры, имея картину существующего положения и разработав модель целевой ИТ – архитектуры, можно создать программу унификации и стандартизации ИТ- решений в компании, что позволит сократить затраты на ИТ в коротком промежутке времени.
Андрей Коптелов, Проблемы теории и практики управления. Выпуск № 01 2010 года
I. Вступление
Архитектура распределяет массы и объемы.Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.
Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути - является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове.
И документации вроде бы много, но она разрознена по репозиториям проектов, Вики системам и т.п. Найти логически целостное описание решения и рекомендации по его использованию крайне сложно, а уж проследить ответвляющиеся частные технические решения по цепочке: от потребностей пользователя, до конечной поставки заказчику, вообще не реально, И это несмотря на то, что для заказчика обычно готовится некая версия на базе типового продукта, доработанного в соответствии с его специфическими потребностями. А ведь иногда бывает так необходимо отследить, например, с кем связан компонент, который предполагается использовать при проектировании нового модуля. С кем он, так сказать, разделен шестью рукопожатиями, и какое пагубное влияние могут оказать все эти неучтенные связи на стабильность его поведения.
Подобная ситуация царит во многих крупных ИТ компаниях. Вроде есть архитекторы и архитектурные советы и прочие атрибуты «высокой» архитектуры, а порядка в этом царстве не наблюдается. По вышеперечисленным симптомам, выходит, что на предприятии свирепствует – «острая архитектурная недостаточность».
Мне стало интересно разобраться со всеми аспектами архитектуры, собрав в данной статье структурированно и последовательно информацию о том, что же такое ИТ архитектура, кто такие ИТ архитекторы, и «с чем их едят».
II. Определение понятия «архитектура»
А что можно думать об архитектуре?Давайте для начала пройдемся по определениям.
Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)
Архитектура системы - принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.Очень скупая формулировка и развернуть ее, проиллюстрировав в полной мере смысл, сложно. Поэтому постараемся сузить проблематику и оттолкнемся от чего-то меньшего, например, составной части этой системы:
Архитектура программного обеспечения (англ. software architecture) - совокупность важнейших решений об организации программной системы. Архитектура включает:Довольно лаконичное определение, дополнив которое можно приблизится к пониманию, что же принято ассоциировать с явлением - ИТ Архитектура.
- выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
- соединение выбранных элементов структуры и поведения, во всё более крупные системы;
- архитектурный стиль, который направляет всю организацию - все элементы, их интерфейсы, их сотрудничество и их соединение (1)
Во-вторых, место «совокупности этих элементов», как части, в более крупных системах, включая поведение, точки взаимодействия и т.п. То есть возможность абстрагирования рассматриваемой архитектуры на более высокий уровень, и соответственно детализация архитектуры в наборы составных архитектур нижнего уровня.
В-третьих, использование всеми участниками - единого подхода для организации решений в процессе производства информационных систем.
Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:
Архитектурный подход (англ. architectural framework) - соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2).Ведь в ходе проектирования, разработки, развития и модернизации программной системы, «совокупность решений о ее организации» (Архитектура), требует постоянного обсуждения со всеми заинтересованными лицами проекта, включая бизнес. Опять же принципиально, чтобы все при этом выстраивали перед собой одну и туже картинку, в том числе учитывающую текущее актуальное состояние архитектуры.
Итак, размявшись на общих положениях и задав направление для исследования понятия Архитектура, продолжим углубляться в суть этого явления.
1. Разделы ИТ Архитекторы
Поскольку понятие ИТ архитектуры охватывает целый букет аспектов производства программных продуктов, начиная еще от определения целей автоматизации и заканчивая аж утилизацией устаревшего в какой-то момент ПО, принято делить его на несколько частей:1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:
- базы данных и хранилища данных;
- информационные потоки (как внутри организации, так и связи с внешним миром).
- область разработки прикладных систем;
- портфель прикладных систем.
- информацию об инфраструктуре предприятия;
- системное программное обеспечение (СУБД, системы интеграции);
- стандарты на программно-аппаратные средства;
- средства обеспечения безопасности (программно-аппаратные);
- системы управления инфраструктурой.
4) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) - целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.
Соответственно для работы с каждым из вышеперечисленных разделов, требуется своя группа заинтересованных лиц, имеющих различную квалификацию и предпочтения, а возможно и цели. Поэтому многочисленные этапы ведения проекта порождают артефакты, описывающие аспекты архитектуры в разных стилях и жанрах. В добавок, они создаются чаще всего разнородными инструментами, используя разнообразные нотации, приемы, представления и т.п.
Стало быть, каждому разделу архитектуры соответствует как минимум одна группа стейкхолдеров, имеющая свои взгляды на представления и методы описания архитектуры. Подыщем определение для этой реалии.
Архитектурная группа описаний (англ. architectural view) - представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).Разобравшись вкратце с концепцией, направлениями и разделами архитектуры, а также выявив несовпадения в представлениях архитектуры разными группами заинтересованных лиц, перейдем к разбору непосредственно самих этих представлений (артефактов), отражающих архитектуру.
2. Представления ИТ Архитекторы
Нередко наблюдаю ситуации, когда очень интересные и перспективные замыслы гинут в болоте непонимания, только лишь из-за оторванности генератора идеи от общего уровня сознания профсообщества. Иными словами, он пытается донести концепцию, которая в его мыслях сложена в цельную и стройную идею, выдавая окружающим лишь ее “огрызки”: «ну ведь остальное и так понятно». А это «остальное» действительно не всегда понятно для электората, и он голосует против бредовой и непонятной с его точки зрения идеи, своим равнодушием и игнорированием. Автор же задумки зачастую просто не смекает, почему же все пошло не так, и отчего никто не проникся чудо решением.По всей вероятности нужна была какая-то подводка. А очень может быть, сначала надо было открыть людям целый новый мир, и только потом, в его свете, доносить эту свою идею. Это сродни тому, как иностранцу, не владеющему твоим родным языком, объяснять на нем теорию относительности Эйнштейна. Особенно если ты ее сам как-то не очень…
Очевидно, что и для эффективного представления архитектурных решений всем заинтересованным лицам, требуется некий способ, позволяющий доступно, но достаточно развернуто донести их суть до максимально широкого круга лиц. Таким способом может служить принятый в организации стандарт - Архитектурное описание и соответствующие методы их поддержания. Для более точного осмысления этого явления, пустим в ход и их определение:
Архитектурное описание (англ. architectural description) - рабочий продукт, использующийся для выражения архитектуры (2).
Архитектурный метод описания (англ. architectural viewpoint) - спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).Тем самым, выделенные архитектурные группы, используя единые архитектурные методы описания, значительно повышают эффективность своей работы, достигая максимально согласованного и целостного восприятия обсуждаемых проблем.
Но можно ли загнать специалистов разных направлений, имеющих разную квалификацию, а возможно и образ мышления, в единые рамки, и действительно ли это так необходимо?
Например, диаграмма, описывающая формирование целей и показателей на основании выявления стекхолдеров, вызовов и их проблематики см. рис.1, по своей природе очень сильно отличается от диаграмм со схемой прокладки сети, а также диаграмм в нотации UML и прочих.
Рисунок 1. Модель выработки целей и показателей
На практике использование разнородных артефактов является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и т.д. по цепочке. Ведь создают все эти артефакты специалисты разных архитектурных групп, которые формировались сами по себе, подбирая годами под себя оптимальные инструменты и методики.
Фиксируя все эти разнообразные описания и представления, возникает резонный вопрос: Как же их объединить в некий всеобъемлющий контекст?
Например, для разработки больших информационных систем еще в конце прошлого века использовали модель Закмана (3), в качестве схемы организации архитектурных артефактов.
Модель Закмана основана на дисциплине классической архитектуры и призвана обеспечить общее толкование архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем.
Сама модель представляется в виде матрицы - таблицы, имеющей пять строк и шесть столбцов, см. рис. 2. Каждая ячейка таблицы – презентует набор артефактов, раскрывающих один из насущных аспектов архитектуры.
Рисунок 2. Представление модели Закмана
Примечательно, что основная идея матрицы помимо того, чтобы вынудить заполнить все ячейки, не пропустив важные характеристики системы, состоит и в определении последовательности заполнения. Ведь только заполнив одни ячейки, открывается возможность на основании их заполнить следующие, пока пазлы не сложатся в цельную картинку. Таким образом, различные по своему представлению архитектурные описания ложатся в разные ячейки матрицы и ею же увязываются в единое архитектурное полотно.
Стоит отметить, что на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Модель Закмана со временем дорабатывалась и послужила прародителем для многих архитектурных каркасов и спецификаций.
Одной из таких актуальных спецификаций является например, графический язык ArchiMate, содержащий набор понятий для описания архитектуры предприятия и фреймворк, представляющий логическую структуру для классификации этой информации Последняя версия стандарта 3.0 вышла в июне 2016 года.
В ArchiMate, при создании моделей, используются базовые понятия «элемент» и «отношение» см. рис.3. На основе элементов и отношений строятся модели предприятия или его отдельных частей.
Рисунок 3. Основные понятия ArchiMate 3.0
Вся прелесть подхода состоит в том, что элементами могут быть проекции самых разнообразных реальных сущностей и явлений, встречающихся в жизни. Например, мотивационные элементы (стейкхолдеры, драйвер мотивации, цель, результат, ценность и т.д.), элементы организации и поведения (исполнители, роли, процессы, функции, события, взаимодействие и т.д.), бизнес элементы (информационный актив, соглашение, продукт/услуга, компонент приложения, интерфейс приложения, автоматизируемая функция и т.д.), технологические элементы (узел/ресурс, устройство, коммуникационная сеть, технологический процесс и т.д.). Каждый вид элемента представлен на диаграммах своим уникальным обозначением. Таким образом в одном информационном пространстве могут сочетаться столь разные отражения сущностей, явлений, событий, действий и т.д., образующих архитектуру предприятия.
Сами модели располагают в одной из ячеек каркаса на пересечении Слоя (уровень представления) и Аспекта. Схематично структура фреймворка представлена на рис. 4.
Рисунок 4. Слои фреймворка ArchiMate 3.0
В качестве Слоев рассматриваются конструктивные субсистемы предприятия, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов:
1) Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия
2) Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия.
3) Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.
Более подробно ознакомится со спецификацией можно в обзоре ArchiMate (4).
Такого рода инструменты позволяют объединить в единое информационное пространство разнородные аспекты архитектуры, используя унифицированное архитектурное описание и методы, обеспечивая трассировку между диаграммами и элементами.
Погрузившись во все эту «карусель» сложностей и разнообразия возникает один немаловажный вопрос: А всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры? На самом деле существует несколько подходов к ее построению, например:
1) Стандартный подход, заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры. На основании выработанных стандартов, описывается базовая (текущая) архитектура, и отталкиваясь от нее, проектируется целевая (новая). Определив разницу, формируют мероприятия по переходу от базовой архитектуры к целевой. Только после этого начинается конструирование, приобретение и разработка компонентов системы. В качестве недостатков, можно выделить: существенные начальные инвестиций, как финансовые, так и временные. Также этот подход может привести к тому, что называется «паралич из-за анализа».
2) Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия.
3) Сегментный подход, опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса. Позволяет сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта. Могут возникнуть проблемы на этапе интеграции сегментов.
3. Резюме раздела
Итак сделаем краткую выжимку из рассмотренного нами материала:- Архитектура предприятия связывает бизнес-потребности предприятия, информационные технологии, процессы стратегического бизнес-планирования, прикладные информационные системы и процессы их сопровождения.
- В процессе разработки и поддержания архитектуры предприятия участвуют разные группы заинтересованных лиц, имеющие различные требования к ее представлениям (архитектурный подход);
- Для удобства, архитектуру принято делить на разделы, соответствующие разным архитектурным зонам и подходам;
- Для разных архитектурных групп и подходов существуют различные группы описания (визуализации) архитектуры.
- Для удобства организации работы с разнородными артефактами используют архитектурные методы описания, представляющие собой специальные фреймворки и спецификации, и позволяющие работать со всеми артефактами в едином визуальном пространстве. Использование подобных конструкций помогает с одной стороны, логически разбить все представления архитектуры на отдельные разделы для упрощения их формирования и восприятия, а с другой – обеспечить возможность рассмотрения целостной архитектуры с изолированных точек зрения или соответствующих уровней абстракции.
- В зависимости от потребностей и возможностей предприятия, можно выбрать один из нескольких архитектурных подходов, различающихся по объему и составу выполняемых работ, что в свою очередь определяет уровень затрат и качество проектирования.
Со следующей частью статьи можно ознакомиться, перейдя по
Первейшей задачей управления является выбор правильных названий... Если названия неверны, то язык не будет соответствовать правде. Если язык не будет соответствовать правде, тогда вещи не достигнут совершенства. Если вещи не достигнут совершенства, то церемонии и музыка не будут процветать. Если церемонии и музыка не будут процветать, то наказания не будут справедливыми. Если наказания не будут справедливыми, люди не будут знать, что нужно делать. Поэтому начальник должен давать только такие названия, которые могут быть выражены словами, а приказывать только то, что может быть выполнено на практике.
Конфуций
В этой лекции мы обсудим наиболее общие характеристики таких понятий, как " Архитектура информационных технологий" и " Архитектура предприятия".
Прежде чем подойти к описанию того, что такое архитектура ИТ, проще отметить, что ею не является. В частности, архитектурой не является более или менее утвержденный список поставщиков и их продуктов типа "Мы используем серверную ОС MS Windows 2003, СУБД MS SQL , все остальное ПО тоже от Microsoft, серверы на платформе Intel и телекоммуникационное оборудование Cisco". Создание стандартного списка поставщиков и уменьшение их количества – это только частичное решение проблемы "кусочной" информатизации. По мнению Gartner, подход к формулировке архитектуры должен основываться на анализе общекорпоративных процессов и переоценке своих бизнес-процессов и поддерживающих их приложений.
Многие люди, в том числе бизнес-руководители и профессионалы в своих предметных областях, считают, что они хорошо разбираются в технологиях, что на самом деле редко соответствует действительности. Для большинства высших руководителей ИТ-технологии ассоциируются с персональным компьютером, о котором они знают некоторые базовые вещи. Это, кстати, является одной из причин, почему многие из них бывают удивлены, когда им пытаются объяснить всю сложность комплекса управления ИТ. Нужен некоторый язык, который бы позволил объяснить о технологиях то, что действительно необходимо знать бизнес-руководителям. Попытки объяснять все в терминах гигабайт , сетевых протоколов и углубления в дебри ИТ приносят мало пользы. Что необходимо понимать, так это базовую структуру архитектуры ИТ и почему все элементы этой архитектуры необходимы.
Современные подходы к формулированию понятия архитектуры ИТ являются попытками предоставить такой язык, понятный и полезный одновременно для бизнес-руководства и для специалистов в области ИТ.
С другой стороны, представление об архитектуре предприятия имеет свои корни в дисциплине, которая получила название "системное мышление ". Основным объектом изучения этой дисциплины является система, когда "целое составляет нечто большее, чем механическая сумма составляющих, т.е. система обладает свойствами, которые отсутствуют у составляющих ее элементов" . Эберхард Речтин (Eberhardt Rechtin), чья цитата была только что приведена, является одним из основателей этого направления мышления.
Еще одно важное замечание состоит в уточнении понятия "Предприятие". Что мы имеем в виду, когда говорим о предприятии в контексте архитектуры? На самом деле, этот термин большинство специалистов по архитектуре и соответствующие методики описания архитектуры трактуют достаточно гибко. Это может быть организация в целом или одно из ее бизнес-подразделений, или же это может быть некоторая совокупность предприятий или организационных единиц в рамках единой цепочки создания добавочной стоимости. Таким образом, под термином "Предприятие" мы здесь и далее имеем в виду формальное объединение , не обязательно связанное с коммерческой деятельностью. Это может быть и государственная организация, и общественное, в том числе неформальное, объединение участников, связанных общей целью. Согласно более общему определению, приведенному в , Предприятие "... представляет собой комплексную систему культурных, технологических и процессных компонент , организованных для достижения целей организации".
То есть вы можете применять архитектурные подходы к целому предприятию, подразделению или даже к отдельной прикладной системе. Все зависит от уровня рассмотрения, степени " связь с возможностями оптимизации бизнес-процессов.
Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В этом плане она дополняет достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL , COBIT и другие.
