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

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

При этом модель используется для сбора и анализа требований к данным и включает в себя такие элементы, как сущности, атрибуты, отношения и количество вхождений Одним из способов моделирования данных на логическом уровне является построение моделей "Сущности-Отношения" (ERM –Entity-Relationship Model).

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

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

Лекция 6. Архитектура приложений.

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

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

В Архитектуре приложений, как правило, выделяют две основные области:

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

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

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

web-браузеры, графический интерфейс "толстого" клиента, мобильные устройства и т.д.

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

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

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

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

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

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

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

системам грозит вывод из эксплуатации (замена) или консолидация;

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

системы, требующие обновления;

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

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

Название системы.

Описание системы.

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

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

"Владелец" системы со стороны бизнеса.

Оценка пользы прикладной системы для бизнеса.

Ответственный со стороны ИТ-подразделения.

Оценка технического состояния.

Оценка возможностей по обеспечению новых потребностей бизнеса.

Дата обновления этой информации.

В общем можно выделить три класса приложений в соответствии со следующими категориями:

базовые транзакционные (или вспомогательные, обеспечивающие, обслуживающие – utility);

информационные (дающие преимущества);

инновационные (стратегические).

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

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

Примерами таких преимуществ от использования ИТ являются:

ускорение цикла выполнения операций (например, принятия решения);

более быстрый вывод на рынок новых продуктов и услуг;

уменьшение производственного цикла;

более высокое качество;

более широкий набор продуктов и услуг;

более глубокая настройка на потребителя;

меньшая стоимость выполнения операций.

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

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

Операции в реальном времени (Real-Time Operations). Примеры: транспортные операции в аэропорту, мониторинг пациентов в клинике.

Аналитические приложения, бизнес-аналитика, поддержка принятия решений (Analytical and Business Intelligence). Примеры: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита.

Приложения поддержки совместной работы (Collaborative). Примеры:

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

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

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

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

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

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

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

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

стратегические потребности;

бизнес-требования;

отличительные характеристики;

интегрирующие технологии.

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

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

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

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

Существуют различные способы категоризации технологий и сервисов, которые относятся к технологической архитектуре. Например, META Group выделяет два различных типа областей (доменов) технологической архитектуры :

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

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

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

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

Сервисы данных: системы управления базами данных (технологии баз данных и методы доступа к базам), хранилища данных (хранилища и витрины данных), системы поддержки принятия решений (Business Intelligence – средства анализа и средства подготовки отчетов).

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

Программное обеспечение промежуточного слоя (middleware).

Вычислительная инфраструктура: операционные системы и аппаратное обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства – ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений/данных, сетевые операционные системы, принтеры), среда для web-инфраструктуры (браузеры, web-порталы, web-серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), системы хранения (Storage Area Network – сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений).

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

Сервисы безопасности: авторизация, аутентификация (внутренняя и внешняя аутентификация, PKI), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

На самом деле, возможных способов классификации элементов, составляющих основу технологической архитектуры, может быть множество. В качестве еще одного примера можно привести техническую справочную модель (TRM) методики Федеральной архитектуры США FEAF, опубликованную на сайте http://www.whitehouse.gov/.

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

Основными характеристиками адаптивной системы (см. также [4.27]) являются:

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

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

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

самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора.

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

Для решения этой задачи предложили свои решения практически все ведущие производители, включая HP (концепция Adaptive Enterprise, архитектура Darwin), IBM (On Demand), Sun (N1), Microsoft (Dynamic Systems Initiative) и другие. Важной частью этих решений является комплексность, использующая как возможности аппаратных платформ, включая разделяемые процессорные разделы, виртуальные дисковые массивы, серверылезвия", так и специализированное программное обеспечение для "оркестровки" существующих ресурсов.

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

Можно выделять два класса – "технологические" и "рамочные" стандарты.

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

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

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

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

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

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

При этом сами профили можно условно разделить на два класса:

– профили, описывающие собственно программные или архитектурные решения на основе ISO 15288, - профили, регламентирующие процессы жизненного цикла программных систем, такие как разработка, тестирование, сопровождение и т.п.

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

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

Одним из удачных определений шаблонов является следующее: "Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте" В приведенном выше определении шаблона имеется три ключевых словосочетания:

Общее решение. Это означает, что шаблон не дает полного законченного решения.

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

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

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

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

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

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

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

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

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

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

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

описание поддерживаемой бизнес-функции;

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

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

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

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

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

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

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

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

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

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

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

Для задач электронного бизнеса соответствующая функциональность SOA реализуется на уровне web-сервисов (служб). Под web-сервисами понимаются программные системы, стандарты Web ServicesDescription Language (WSDL) для описания своих интерфейсов, Simple Object Access Protocol (SOAP) для описания формата принимаемых и посылаемых сообщений и стандарт Universal Description, Discovery and Integration (UDDI) для создания каталогов доступных сервисов. И хотя принципы сервис-ориентированной архитектуры создания информационных систем не обязательно предполагают использование технологий web-сервисов, связь между этими двумя направлениями в развитии информационных технологий является достаточно тесной. При этом webсервисы являются технологическими спецификациями, в то время каксервисориентированная архитектура (SOA) является принципом проектирования архитектуры программных систем.

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

Эта модель состоит из следующих основных компонент:

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

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

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

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

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

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

MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах :

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

построение систем может быть организовано в соответствии с рамочной системой моделей, которые позволяют отделить бизнес-логику приложений от конкретной реализации. Исходной является так называемая независимая модель вычислений (Computational Independent Model), которая путем последовательных трансформаций через платформо-независимые (PIM) и платформо-специфичные модели (PSM) автоматически или с минимальным участием программиста приводится к исполняемому коду и соответствующим структурам данных;

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

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

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

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

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

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

Лекция 8. Методики описания архитектур.

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

методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;

модель Захмана;

методика TOGAF;

методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

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

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

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

Существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – Institute of Electrical and Electronics Engineers), международная организация стандартизации (ISO – International Organization for Standardization), The Open Group и т.д. Но ни один из этих стандартов не занимает доминирующего положения. Более того, ни один из них, взятый в отдельности, не дает группам, ответственным за разработку архитектуры, всех инструментов, необходимых с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей, примеров и опыта различных индустрий Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем.

Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for EnterpriseArchitecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

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

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

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

порядок следования колонок несущественен;

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

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

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

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

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

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

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

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

Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

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

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

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

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

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

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

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

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

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

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

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

На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:

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

бизнес-стратегии и основные движущие силы с точки зрения бизнеса;

требования к информационным системам со стороны бизнеса;

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

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

Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состоянием архитектуры.

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

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

В полном описании методики META Group приводятся также следующие аспекты:

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

вопросы управления и контроля архитектурного процесса (governance);

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

анализ технологических тенденций и планирование;

управление портфелем ИТ-активов и проектов.

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

методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.

В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:

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

Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.

Фаза B: разработка бизнес-архитектуры предприятия.

Фаза C: разработка архитектуры данных и архитектуры приложений.

Фаза D: разработка технологической архитектуры.

Фаза E: проверка возможности реализации предложенных решений.

Фаза F: планирование перехода к новой системе.

Фаза G: формирование системы управления преобразованиями.

Фаза H: управление изменением архитектуры.

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

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

Принципы являются взаимозависимыми и должны применяться в целостном наборе.

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

Лекция 9. NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие.

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

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

области или домены (Domains) ИТ-архитектуры;

дисциплины;

технологические дисциплины;

продуктовые компоненты;

документы соответствия.

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

управление приложениями;

управление данными;

управление информацией;

интеграция;

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

сети и коммуникации;

платформы;

управление системами;

информационная безопасность и т.п.

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

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

Например, в домен Управление системами входят, в том числе, следующие дисциплины:

Управление активами (Asset management).

Управление изменениями (Change management).

Управление событиями (Event Management).

Поддержка пользователей (HelpDesk).

Обеспечение непрерывности бизнеса (Business continuity) и др.

Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологическиеразделы архитектуры. В качестве примера можно привести Дисциплину "Управление данными" (Data Management), которая является частью Области "Информация". Дисциплина "Управление Данными" может включать в себя такие Технологические Области, как:

реляционные СУБД;

плоские файловые системы;

настольные базы данных;

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

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

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

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

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

документирование;

рецензирование;

информирование;

проверка соответствия;

поддержка актуальности;

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

Модель "4+1" представления архитектуры. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте архитектуры предприятия – что, собственно, и произошло на практике.

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

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

Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).

Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.

Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.

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

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

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

Стратегическая модель архитектуры SAM. Методика Стратегическая модель архитектуры SAM (Strategic Architecture Model) является интересным инструментом анализа и документирования архитектуры предприятия и связанных с ней доменов.

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

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

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

Либо же заполнение может идти в направлении "сверху–вниз" с постепенной декомпозицией на более мелкие детали.

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

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

Можно выделить три категории сфер:

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

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

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

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

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

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (MSM), которые мы рассмотрим ниже.

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

MSF – "Как правильно создавать ИТ-системы?" MSA – "Как правильно создавать технологическую инфраструктуру?" MOF – "Как правильно эксплуатировать технологическую инфраструктуру?" MSM – "Как правильно строить процессы управления технологической инфраструктурой?" Microsoft выделяет два типа руководств и обеспечивающих методик, которые могут помочь системным архитекторам ускорить процессы разработки моделей при минимизации рисков.

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

общее понимание и язык описания архитектуры;

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

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

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

Помимо неоднократно упоминавшейся нами методики Федеральной архитектуры США FEAF, в частности, могут быть полезными многочисленные примеры как шаблонов, так и готовых документов, определенные в методиках TEAF и С4ISR.

TEAF (http://www.ustreas.gov/) – архитектура Казначейства США, которая построена на основе федеральной архитектуры государственных организаций (FEAF), но проработана существенно глубже, чем первая, в силу того, что предназначается для отдельной организации. В состав TEAF включены шаблоны документов для большинства рассматриваемых областей.

C4ISR (http://www.defenselink.mil/) – архитектура, разработанная в 1996-98 гг. в Министерстве обороны США, содержит, помимо шаблонов, еще и значительное количество интересных примеров, хотя и немного устаревших. C4ISR (Command, Control,Communications, Computers, Intelligence, Surveillance and Reconnaissance) можно перевести как "Командование, Управление, Коммуникации, Компьютеры, Информация, Наблюдение и разведка".

С декабря 2003 года ее заменила так называемая рамочная архитектура Министерства см. http://www.defenselink.mil/nii/doc/DoDAF_v1_Memo.pdf).

Лекция 10. Процесс разработки архитектур.

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

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

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

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

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

понимание стратегии развития бизнеса организации;

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

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

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

Определение и обоснование цели – ответы на вопросы Почему? и Что?

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

Определение существующего состояния архитектуры ( "as is") для каждой выбранной области (домена) – отправная точка ответа на вопрос Где?

Определение целевой архитектуры – конечная точка ответа на вопрос Где?

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

Разработка плана перехода – ответы на вопросы Когда? и Как?

Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений?

Выполнение намеченного плана.

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

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

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

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

Семь шагов архитектурного процесса в соответствии с методикой Спивака. Модель называется EAP (Entrerprise Architecture Planning – Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архитектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции). Эти 7компонент, условно изображенных на рисунке в виде "свадебного торта", обозначают смещение фокуса приложения сил на каждом из шагов.

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

в основе – потребности бизнеса, а не технологические факторы;

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

ответственность за процесс в большей степени несут представители бизнесподразделений, чем специалисты по ИТ.

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

Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является систематическое и рекурсивное применение таких принципов, как:

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

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

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

Эта схема состоит из следующих шагов:

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

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

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

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

Параллельно с этими процессами выполняется анализ на "системном уровне":

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

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

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

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

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

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

Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры:

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

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

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

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

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

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

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

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

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

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

Этап 3: Разработка Плана реализации Этап 3 включает в себя следующие два шага:

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

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

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

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

Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF).

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

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

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

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

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

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

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

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

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

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

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

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

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

уровень внесения существенных изменений в архитектуру;

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрение элементов ИТ-архитектуры ведется обычно в двух аспектах: а) планирование и управление ИТ-системами, и б) стандарты и общие службы (компоненты).

Аспект планирования и управления включает:

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

принципы реализации – определяют "правила" рассмотрения, внедрения и последующего управления технологиями;

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

Аспект стандартизации включает:

Общие ИТ-службы. Сюда относятся кросс-функциональные и служебные приложения, такие как электронная почта.

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

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

Лекция 12. Процесс разработки архитектур: оценка зрелости. (Групповая дискуссия) отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней:

Уровень 1. Начальный.

Уровень 2. Повторяемый.

Уровень 3. Определенный или регламентируемый.

Уровень 4. Управляемый.

Уровень 5. Оптимизирующий.

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

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

изучение, осознание и коммуницирование бизнес-стратегии;

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

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

вовлечение конечных пользователей архитектуры в процесс;

реализация философии "постоянных изменений";

поиск архитекторов с нужным уровнем знаний.

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

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

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

Для удовлетворения этих специфических потребностей в обеспечении архитектурного процесса появился целый класспрограммных продуктов. Перечислим названия некоторых компаний-разработчиков таких систем, многие из которых, за исключением последней, практически неизвестны на российском рынке: Casewise, Computas, Framework Software, Popkin Software, Proforma, Ptech, Rational Software.

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

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

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

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

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

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

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

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

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

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

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

географические и организационные кросс-ссылки. Разные организационные структуры могут иметь различный набор систем;

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

Краткое описание лабораторных работ 5.3.1 Перечень рекомендуемых лабораторных работ 1. Анализ предметной области.

2. Средства моделирования при проектировании информационной системы.

3. Формирование требований к информационной системе.

4.Спецификация требований к информационной системе 5. Проектирование пользовательского интерфейса к информационной системе.

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

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

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

5.3.2 Методические указания по выполнению лабораторных работ 1. Анализ предметной области.

Цель работы: Приобретение навыков анализа состояния предметной области с целью определения перспектив построения или модернизации информационной системы.

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

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

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики должны научиться 1. · понимать язык, на котором говорят заказчики;

2. · выявить цели их деятельности;

3. · определить набор решаемых ими задач;

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

Порядок выполнения работы:

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

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

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

- Сформулировать проблемы в организации Сформулировать 2-3 основные проблемы, руководствуясь материалом по теме «Основы системного анализа».

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

- имеющегося персонала;

- технических и программных средств;

- информационных систем;

- возможного развития этих ресурсов на ближайшие несколько лет.

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

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