Опубликован: 07.05.2007 | Доступ: свободный | Студентов: 11053 / 2888 | Оценка: 4.16 / 3.71 | Длительность: 23:54:00
ISBN: 978-5-9556-0045-1
Специальности: Руководитель
Лекция 4:

Интегрированная концепция и уровни абстракции

Архитектура предприятия в России

В отличие от значительного внимания, которое уделяется вопросам Архитектуры предприятия на Западе, в российской практике этот вопрос изучен гораздо хуже. Следует обратить внимание читателей на серию работ группы Е.З. Зиндера, которые сделаны, в том числе, в рамках Фонда ФОСТАС (Фонда поддержки системного проектирования, стандартизации и управления проектами, www.fostas.ru). Кроме этого, можно отметить буквально единичные концептуальные публикации, которые посвящены предмету нашего рассмотрения. Скорее всего здесь, в России, мы являемся больше "наблюдателями" процессов развития теоретической мысли за рубежом, связанных с использованием архитектурных подходов к созданию корпоративных информационных систем.

Это тем более досадно, поскольку в ряде российских компаний, включая некоторые телекоммуникационные, нефтедобывающие и финансовые структуры, а также отдельные, увы, немногочисленные, государственные организации, созданы сложные, современные и весьма эффективные информационные системы, которые реализуют на практике многие лучшие, а иногда и оригинальные, архитектурные решения. Достаточно высокая активность обсуждения архитектуры происходит прежде всего в отдельных "нишевых" областях, в которых в силу исторических и различных других объективных причин получили распространение отечественные разработки программных систем. Хорошим примером является обсуждение архитектуры автоматизированных банковских систем – форум на сайте http://www.o-t-r.ru/expert/conference.

В работе Н. Михайловского [3.23] основное внимание акцентируется на процессе оптимизации архитектуры. В качестве основного критерия при выборе такой оптимальной конфигурации предлагается использовать принцип минимизации совокупной стоимости владения. При этом оценка совокупной стоимости владения должна включать не только фактические затраты, но и потери, связанные с бизнес-рисками. Отметим, что данный подход расширяет традиционную оценку рисков путем учета не только потерь от технических рисков из-за простоев и сбоев, как это принято, например, в модели TCO, но и учета рисков бизнес-потерь, связанных с несовершенством реализации системы или изменчивостью бизнес-процессов. Характерным примером может являться отказ покупателя Интернет-магазина от покупки из-за неудобной процедуры выбора товара. Как правило, если для технических рисков часть данных обычно известна из литературы (такие параметры как среднее время наработки на отказ для серверного кластера или дискового массива), то получение оценок для бизнес-рисков гораздо сложнее. Соответственно, в данной работе предлагается учесть влияние бизнес-рисков на архитектуру с использованием специальным образом формируемой матрицы соответствия технических и бизнес-рисков. Те бизнес-риски, которые не зависят от варианта реализации системы (например, централизованная или клиент-серверная архитектура), исключаются из критерия выбора. Совокупная стоимость владения оценивается с учетом сформированной матрицы соответствия технических и бизнес-рисков, а также вариантов реализации инфраструктуры системы. Оптимальна будет архитектура с минимальной суммарной стоимостью владения.

Практический опыт разработки ИТ-архитектуры на примере крупного банка иллюстрируется в статье В. Галактионова [3.24]. Здесь используется термин "системная архитектура", которая позиционируется автором, наряду с бизнес-архитектурой и стратегией предприятия, одной из составных частей общего понятия "Архитектура предприятия". При этом бизнес-архитектура включает в себя описания продуктов и услуг, каналов продаж, функций и процессов, документов, информационных потоков, а также организационную структуру. В составе системной (ИТ) архитектуры автор выделяет три компоненты – архитектуру приложений, данных и техническую архитектуру. Последняя, в свою очередь, включает сетевую архитектуру и архитектуру платформ.

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

Другим важным тезисом является представление о многослойной модели архитектуры. Действительно, ИТ-архитектура в целом, как и отдельные программные средства, характеризуется определенным жизненным циклом. Этот жизненный цикл архитектуры включает такие фазы, как "начальное документирование, использование, проектирование и миграцию". Для программных средств процессы жизненного цикла определены, например, в стандарте ISO/IEC 12207. Для ИТ-архитектуры существуют и другие определения фаз (подробнее см. в лекциях 10-12). Каждый слой соответствует определенному "временному срезу" состояния компонент архитектуры, так что миграция (реализация проекта на практике) связана с переходом к следующему слою – здесь прослеживается определенная аналогия с моделью "3D-предприятия" (см. "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" ).

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

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

В статье М. Аншиной (Открытые системы, №11, 2004) отмечается, что и архитектура, и стратегия ИТ являются сложными и многоплановыми понятиями, так что для их представления может быть удобно использовать метафору "матрешки". Здесь тоже предлагается на концептуальном уровне расширение модели Захмана путем добавления специфических осей, таких как функциональная, финансовая или ось стандартов.

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

Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?