«ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА ДИСЦИПЛИНЫ (рабочая учебная программа дисциплины) Архитектура информационных систем Направление подготовки 230400 Информационные системы и технологии Профили подготовки Информационные системы и ...»

Министерство образования и науки Российской Федерации

ФГБОУ ВПО

«ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ

УНИВЕРСИТЕТ»

Факультет кибернетики_

Кафедра автоматизированных систем

ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА ДИСЦИПЛИНЫ

(рабочая учебная программа дисциплины) Архитектура информационных систем Направление подготовки 230400 «Информационные системы и технологии»

Профили подготовки Информационные системы и технологии в административном управлении Квалификация (степень) _бакалавр_ Форма обучения очная_ Составитель программы _Бахвалов Сергей Владимирович, к.т.н., доцент кафедры_ _ автоматизированных систем Иркутск 2013 г.

1.Информация из ФГОС, относящаяся к дисциплине 1.1. Вид деятельности выпускника Дисциплина охватывает круг вопросов относящихся к проектно-конструкторской, организационно-управленческой, научно-исследовательской, инновационной видам деятельности выпускника 1.2. Задачи профессиональной деятельности выпускника В дисциплине рассматриваются указанные в ФГОС задачи профессиональной деятельности выпускника:

- техническое проектирование (реинжиниринг);

- чтение и понимание основных видов документации в сфере профессиональной деятельности;

- участие в разработке IT-инфраструктуры предприятий и организаций в сфере профессиональной деятельности;

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

- организация рабочих мест, их техническое оснащение, размещение компьютерного оборудования;

- обеспечение междисциплинарного научного обмена;

- согласование стратегического планирования с информационно-коммуникационными технологиями (ИКТ), инфраструктурой предприятий и организаций;

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

- способность проводить техническое проектирование (ПК-2) - способность понимать и читать основные виды документации в сфере профессиональной деятельности (ПК-11 ) - способность участвовать в разработке IT-инфраструктуры предприятий и организаций в сфере профессиональной деятельности (ПК-12 ) - способность разработки моделей информационных систем и технологий на всех этапах ее жизненного цикла в соответствии с требованиями CALS-технологий (ПК-16), - способность осуществлять организацию рабочих мест, их техническое оснащение, размещение компьютерного оборудования (ПК-30), - способность обеспечивать междисциплинарный научный обмен (ПК-44), - способность согласовывать стратегическое планирование с информационнокоммуникационными технологиями (ИКТ), инфраструктурой предприятий и организаций (ПК-49).

1.4. Перечень умений и знаний, установленных ФГОС После освоения программы настоящей дисциплины студент должен:

знать:

- классификацию информационных систем, структуры, конфигурации информационных систем, общую характеристику процесса проектирования информационных систем;

- виды архитектур информационных систем ( централизованные, « файл – сервер », «клиент - сервер», распределенные, веб – приложения, сервис - ориентированные) - состав, характеристики, области применения и особенности эксплуатации информационных систем различной архитектуры;

- типовые решения (шаблоны) проектирования и реализации информационных систем различного назначения;

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

уметь:

- применять информационные технологии при проектировании информационных систем;

- использовать архитектурные и детализированные решения при проектировании систем;

- выбирать соответствующую задаче архитектуру информационной системы;

- применять готовые шаблоны проектирования и разработки информационных систем;

- проводить анализ предметной области, выявлять информационные потребности и разрабатывать требования к ИС;

- разрабатывать концептуальную модель прикладной области.

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

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

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

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

Задачи дисциплины:

- сформировать у студентов системные знания в области архитектуры информационных систем (ИС);

- ознакомить студента с понятием архитектуры ИС и ее составляющими.

- изучить способы разработки архитектуры ИС;

- сформировать навыки работы с литературными источниками и нормативно-правовыми материалами по формированию архитектуры ИС;

3. Место дисциплины в структуре ООП Для изучения дисциплины необходимо освоение содержания дисциплин:

Информатика (ОК-3,ОК-6,ПК-43,ПК-51 ), Знания и умения, приобретаемые студентами после освоения содержания дисциплины, будут использоваться в дисциплинах:

Теория информационных процессов и систем (ПК-9,ПК-17,ПК-18,ПК-21,ПК-38,ПКТехнология программирования (ОК-6,ПК-17,ПК-18,ПК-23,ПК-47,ПК-58), Управление данными (ПК-14,ПК-17,ПК-18,ПК-55), Методы и средства проектирования информационных систем (ПК-1,ПК-2,ПК-3,ПК-4,ПК-10,ПК-15,ПК-16,ПК-17,ПК-19,ПКПК-23,ПК-57,ПК-61), Инфокоммуникационные системы и сети (ОК-6,ПК-12,ПКПК-17,ПК-18,ПК-23,ПК-51,ПК-52), Интеллектуальные системы и технологии (ОКПК-17,ПК-18,ПК-23).

Основная структура дисциплины Вид промежуточной аттестации (итогового Экзамен (36) Экзамен (36) контроля по дисциплине) 5. Содержание дисциплины 5.1. Перечень основных разделов и тем дисциплины Раздел 1 Введение. Предмет, цели и задачи курса. Состав, структура курса.

Раздел 2. Бизнес и информационные технологии. (Интерактивная лекция) Рассматривается роль ИТ в бизнесе, актуальность проблемы разработки ИТ-стратегии и ИТ-архитектуры, роль ИТ-стратегии и ИТ-архитектуры в изменениях бизнеса, эволюции ИТ, бизнес-стратегий.

Раздел 3. Архитектура предприятия: основные определения.

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

Приводятся контекст, уровни абстракции, домены описания, управление архитектурой, общие элементы определений "Архитектуры предприятия".

Раздел 5. Бизнес-архитектура и архитектура информации.

Приведены основные домены, принципы, модели и стандарты архитектуры, модели описания архитектуры Раздел 6 Архитектура приложений.

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

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

Рассматриваются контекст разработки архитектуры, модели описания Захмана, Gartner, META Group, TOGAF Раздел 9. NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие.

Рассмотрены модели описания NASCIO, "4+1", SAM, Microsoft и др Раздел 10. Процесс разработки архитектур.

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

Рассмотрены элементы и методы управления и контроля, организационные вопросы, анализ затрат и несоответствий Раздел 12. Процесс разработки архитектур: оценка зрелости. (Интерактивная лекция) Рассмотрены характеристики уровней организации, качественные и количественные критерии "хорошей" архитектуры, инструментальные средства.

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

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

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

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

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

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

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

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

Дисциплина читается в 3 семестре, итоговый вид контроля экзамен. Общее количество 180 часов (5 ЗЕТ), лекций 51 час, лабораторных работ 34 часа, самостоятельная работа часов.

Лекция 2. Бизнес и информационные технологии (Интерактивная лекция 2 час) Можно проследить интересную аналогию между архитектурой здания и архитектурой информационной системы организации. Наряду с характеристиками, описывающими состав, структуру и назначение компонент информационной системы, ее реальный эффект во многом будет определяться субъективными аспектами восприятия со стороны пользователей. Хорошо продуманныйинтерфейс пользователя и поддержка всех тех функций, которые реально нужны на практике, обеспечат успех информационных систем и создадут предпосылки для успеха организации в целом. Напротив, морально устаревшие приложения и архаичные технические средства скорее мешают, нежели способствуют продуктивной работе, и их судьба будет схожа со сносимыми постройками.

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

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

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

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

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

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

происходящими изменениями в самом бизнесе и индустриальном обществе;

изменением роли информационных технологий в бизнесе и обществе;

изменением корпоративной культуры и стиля управления в бизнесе;

а также с объективным увеличением ИТ-бюджетов компаний.

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

глобализация бизнеса, связанная с необходимостью объединения различных национальных процессов, данных и персонала;

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

появление адаптивного стиля бизнеса – переход от модели, основанной на имеющейся линейке продуктов (т.н. "make-and-sell"), к модели, основанной на гибком реагировании на потребности рынка – ("sense-and-respond"). Этот стиль связан с признанием неизбежности и непредсказуемости изменений во внешней среде. Компании, принявшие такую модель, связывают достижение успеха с осуществлением таких преобразований в бизнес-процессах и организационной структуре, которые могли бы оперативно и адекватно подстраиваться под происходящие изменения;

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

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

концентрация на основных компетенциях;

максимально возможная передача непрофильной деятельности внешним поставщикам услуг (аутсорсинг), а в ряде случаев и аутсорсинг управления проектами;

систематическая разработка и реализация инноваций;

расширение полномочий нижестоящих менеджеров – иерархическая структура управления как бы "раздается вширь";

активность в образовании альянсов, в том числе частичное сотрудничество с конкурентами;

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

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

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

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

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

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

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

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

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

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

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

Бизнес-стратегия должна идентифицировать направления развития бизнеса (основной области деятельности) организации и причины движения в данном направлении.

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

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

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

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

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

Ценность информационных технологий для организации реализуется через создание и использование трех независимых видов ресурсов:

человеческий капитал (компетентный, высоко мотивированный персонал службы ИТ, сфокусированный на обеспечении потребностей бизнеса организации);

технологии (совместно используемые данные и платформы);

взаимосвязи между ИТ и бизнесом (взаимное понимание, совместное принятие на себя рисков и ответственности).

Эти три ресурса одновременно создаются и используются за счет реализации трех ключевых ИТ-процессов:

инновации в области ИТ – идентификация и планирование создания соответствующих прикладных систем;

процесс создания систем – проектирование, покупка, разработка, конфигурирование и внедрение;

услуги по сопровождению и эксплуатации – операционное сопровождение и поддержка систем в период после внедрения.

Три наиболее важных тенденции в области управления ИТ:

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

Дисциплинированное управление проектами. Практика: управление проектами (включая создание групп управления проектами, использование стандартных методик, таких как модель уровня зрелости (Capability Maturity Model – CMM), предложенная Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона).

Четкая оценка результатов (value clarification). Практики: анализ результатов внедрения систем, оценка деятельности департамента ИТ, наличие соглашений об уровне обслуживания бизнес-подразделений службой ИТ (SLA – Service Level Agreement), использование четких правил обоснования новых проектов.

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

масштаб и повсеместная распространенность технологий;

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

интеграция бизнес-процессов на корпоративном уровне, обеспечиваемая использованием ИТ.

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

Лекция 3. Архитектура предприятия: основные определения Прежде чем подойти к описанию того, что такое архитектура ИТ, проще отметить, что ею не является. В частности, архитектурой не является более или менее утвержденный список поставщиков и их продуктов типа "Мы используем серверную ОС MS Windows 2003, СУБД MS SQL, все остальное ПО тоже от Microsoft, серверы на платформе Intel и телекоммуникационное оборудование Cisco". Создание стандартного списка поставщиков и уменьшение их количества – это только частичное решение проблемы "кусочной" информатизации. По мнению Gartner, подход к формулировке архитектуры должен основываться на анализе общекорпоративных процессов и переоценке своих бизнес-процессов и поддерживающих их приложений.

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

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

Под термином "Предприятие" мы здесь и далее имеем в виду формальное объединение, не обязательно связанное с коммерческой деятельностью.

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

Первый подход связан с реорганизацией, реинжинирингом процессов, а второй – с управлением знаниями.

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

Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В этом плане она дополняет достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие.

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

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

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

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

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

Термин "ИТ-архитектура" может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл одного и того же термина может быть разным. Каждый из нас, на самом деле, может достаточно быстро сформулировать интуитивное определение, которое после анализа окажется вполне применимым. Известных формальных определений архитектуры существует несколько сотен. Для этого достаточно зайти на сайт Института Проектирования Программного Обеспечения Карнеги-Меллона (SEI – Carnegie Mellon Software Engeneering Institute) www.sei.cmu.edu. Одно из самых простых (словарь Уэбстера) заключается в том, что ИТ-архитектура – это "способ, который используется для организации и интеграции компонент компьютерной системы".

"Архитектурный взгляд" на системы (как ИТ-системы, так и бизнес-системы) определен в стандарте ANSI/IEEE 1471-2000 как "фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии" В самом общем виде, в соответствии с определениями Gartner, архитектура – это:

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

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

Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.

Еще несколько определений:

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

"Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий" (Giga Group);

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

Рассмотрим теперь более подробно, какие отдельные понятия в рамках представления об "архитектуре" существуют, и как они связаны между собой. Можно выделить, по крайней мере, 3 различных "измерения" в данном континууме определений:

иерархия архитектур различных организационных систем;

соотношения между объективной реальностью и субъективным восприятием;

соотношения между общесистемной архитектурой и частными архитектурами.

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

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

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

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

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

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

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

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

собственно архитектура информационной системы – как объективная реальность, включающая существующие компоненты и их связи;

описание архитектуры (architecture description) – отражение объективной или планируемой реальности в какой-либо документированной форме.

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

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

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

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

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

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

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

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

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

Следующей ступенью явилось понятие Корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). Стало понятно, что усилия по описанию архитектуры предприятия должны включать в себя описание архитектуры информации и архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем.

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

Такой подход обеспечивает более эффективное взаимодействие различных структурных подразделений организации:

совместный доступ к информации различных подразделений, а также внешних организаций (клиентов, партнеров, поставщиков);

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

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

Формальное описание архитектуры предприятия впервые было сформулировано в IFAC/IFIP (International Federation of Automatic Control / International Federation for Information Processing). Идея состояла в том, чтобы разработать максимально общую, так называемую эталонную (reference) модель архитектуры предприятия, которая охватывала бы дополнительно процесс развития предприятия во времени как проект, а также учитывала бы роль человеческого фактора. Архитектуры отдельных подсистем, в том числе ИТ-системы предприятия, могут быть тогда разработаны как специфические уточнения такой общей модели. Разработанная как приложение к данному стандарту, такая общая эталонная модель архитектуры получила название GERAM (Generalized Enterprise Reference Architecture and Methodology).

В документах Финансово-контрольного управления США приводится определение:

"Архитектура предприятия описывает деятельность предприятия с двух позиций:

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

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

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

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

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

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

автоматизации процессов – там, где видится положительный возврат от инвестиций в технологии (ROI);

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

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

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

формирование портфеля прикладных систем (определение архитектуры приложений), которые обрабатывают эту информацию в соответствии с некоторыми функциональными требованиями;

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

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

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

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

Лекция 4. Интегрированная концепция архитектуры предприятия Архитектура предприятия является динамичным и мощным инструментом, который помогает организациям в процессе понимания своей собственной структуры и способов выполнения своей работы и функций. Она обеспечивает "карту" предприятия и "план маршрута" по изменению как в бизнес-областях, так и в области технологий.

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

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

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

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

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

системные архитекторы, которые отвечают за создание архитектуры отдельных информационных систем;

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

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

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

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

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

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

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

перспектива (perspective) или уровень абстракции;

представление (view) или предметная область, домен архитектуры.

Большинство методик разделяет проблему описания архитектуры предприятия на некоторое количество представлений или предметных областей (доменов), таких как:

бизнес-архитектура – люди и процессы;

архитектура информации – данные, информация и знания;

архитектура прикладных систем;

технологическая архитектура.

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

как архитектура интеграции или архитектура общих сервисов.

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

уровень контекста – ориентирован на бизнес-руководство;

концептуальный уровень или "Видение Общих Требований" – ориентирован на "владельцев" бизнес-процессов;

логический уровень – ориентирован на архитекторов и проектировщиков систем;

физический уровень – ориентирован на проектировщиков и разработчиков систем.

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

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

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

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

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

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

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

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

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

Примеры вопросов, на которые должен давать ответ уровень контекста:

Каких целей хочет добиться организация?

Почему организация занимается таким бизнесом: видение, миссия и цели?

Каковы тенденции в индустрии, в которой работает организация?

Как организация расположена и где она работает географически?

Каковы факторы, определяющие достижение высоких результатов в бизнесе (value drivers)?

Каковы на самом высоком уровне классы информации, которыми оперирует организация?

Каковы функции этого бизнеса?

В каких областях сосредоточена ключевая компетенция организации?

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

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

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

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

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

Ключевые вопросы, которые рассматриваются на данном уровне, следующие:

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

Какая общая бизнес-архитектура (например, "фронт-офис", "мид-офис", "бэкофис") будет использоваться?

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

Как выглядят бизнес-процессы, которые обеспечивают создание продуктов и оказание услуг?

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

Организован ли бизнес организации в централизованном или децентрализованном виде?

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

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

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

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

В качестве методов, которые используются для построения бизнес-моделей на этапе концептуального проектирования, могут быть, например, такие инструменты языка UML как Варианты Использования (Use Cases), диаграммы деятельности и другие методы проектирования процессов.

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

На этом уровне даются ответы на следующие вопросы:

Какие приложения необходимы для поддержки бизнес-процессов?

Кто является основными пользователями и заинтересованными сторонами в реализации данных прикладных систем?

Как выглядят нормализованные модели данных для этих приложений?

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

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

Как будет выглядеть распределенная архитектура прикладных систем?

Какие стандарты должны быть приняты организацией?

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

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

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

Как логические компоненты будут распределены между различными системами (будут ли эти компоненты реализованы в виде web-сервисов)?

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

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

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

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

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

Примеры вопросов, на которые отвечают на данном уровне абстракции, следующие:

Каковы функциональные спецификации каждой прикладной системы?

Будет ли организация разрабатывать специализированные приложения или покупать стандартные?

Каковы критерии выбора и как будут оцениваться различные инициативы по реализации систем?

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

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

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

для системы факторов. Рассматриваются средства коммуникаций, Логический Моделируется внутренняя архитектура системы.

Физический Моделируется физическая структура реализации системы.

Общие элементы определений, связанных с архитектурой:

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

архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;

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

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

каждая система имеет архитектуру – даже система, которая состоит из одной компоненты;

архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;

определения архитектуры не содержат описания самих компонент.

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

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

Лекция 5. Бизнес – архитектура и архитектура информации.

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

Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов.

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

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

Технологическая архитектура (инфраструктура или системная архитектура).

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

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

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

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

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

Архитектура безопасности и т.д.

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

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

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

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

Цели, задачи и стратегии.

Архитектура информационных технологий.

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

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

Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.

Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

Примеры общих принципов, связанных с архитектурой в целом:

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

Функциональное руководство и руководство в области ИТ должно основываться на общем видении.

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

Функциональные (бизнес-) требования должны формировать архитектуру.

Архитектура должна обеспечивать совместимость и взаимодействие.

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

Архитектура должна быть инструментом реализации изменений.

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

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

Примеры декларируемых принципов в области ИТ-инфраструктуры:

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

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

Примеры принципов в области управления данными:

Бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают за целостность и распространение данных.

Данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам).

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

Данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности.

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

Примеры принципов, связанных с прикладными системами:

Прикладные системы разрабатываются на основе стандартной, единой методологии.

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

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

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

Примеры принципов, связанных с управлением и контролем:

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

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

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

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

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

При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты :

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

Определяйте стандарты процессов. Примерами являются процессы бизнесмоделирования, методы разработки систем, тестирования, интеграции.

Уделяйте внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.

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

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

Стандарты должны включать способы проверки на соответствие.

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

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

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

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

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

Наиболее эффективные руководства, как правило, короткие и специфичные.

Желательно ограничивать их четырьмя страницами.

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

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

формальные (использующие общепринятые правила, нотации и средства) и неформальные ;

количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы;

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

Примерами качественных и описательных моделей являются:

текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса), либо обычный текст;

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

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

Примерами количественных моделей могут служить:

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

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

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

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

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

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

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

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

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

При этом можно сказать следующее:

Нет и не стоит в ближайшее время ожидать одной, универсальной технологии создания моделей.

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

Контекст и основные элементы бизнес-архитектуры.

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

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

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

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

Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы "точкой соприкосновения" между бизнесархитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.

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

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

Каков внешний контекст деятельности организации?

В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?

Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?

Какие необходимы информационные взаимосвязи и процессы обработки информации?

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

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

Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно.

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

декомпозиция функций/процессов;

анализ бизнес-событий;

моделирование местоположений выполнения функций/процессов;

модель интеграции функций/процессов.

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

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

идентифицировать основные процессы, обеспечивающие выполнение функций организации;

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

идентифицировать пересечения и излишние функции/процессы.

В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции.

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

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

Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией. Архитектура должна описывать как те данные, которые требуются для выполнения процессов (операционные), так и аналитические данные и "контент", публикуемый на Web.

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

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

В ходе разработки архитектуры информации решаются следующие задачи:

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

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

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

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

интеграция метаданных, что позволит обеспечить целостное представление данных из различных источников;

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

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

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

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

Рекомендуемыми первыми шагами на пути создания архитектуры информации являются следующие шаги:

создание словаря данных и репозитория метаданных;

выбор системы записи информации о каждом элементе данных.

Эти шаги впоследствии будут способствовать созданию оперативного хранилища данных (ODS – Operational Data Store), которое обеспечивает стандартные процессы извлечения, трансформации и загрузки данных (ETL – Extract, Transform, Load), а такжеочистки данных и создания метаданных. Оперативное хранилище является краеугольным камнем для повторного, многократного использования данных, а в последующем – для создания хранилищ и витрин данных.

Результатами процесса разработки архитектуры информации являются:

документированное описание существующих источников данных;

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

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

описание решений по организации хранения данных – от общих каталогов до витрин и хранилищ данных;

используемые технологии и средства для преобразования и управления данными.

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

рассматриваются на бизнес-уровне без описания проблем практической реализации.