• методологии, технологические области;
• требования к документированию.
Технологическая область:
• описание, ссылка на функциональную область;
• обоснование выбора единственного или множественных продуктов (вендоров, приложений).
Продукт/приложение:
• описание, ссылка на технологическую область;
• информация о вендоре, классификация;
• условия использования, политика миграции.
Важным преимуществом такого подхода является возможность представления всего описания архитектуры в виде гипертекстовой базы данных, что позволяет эффективно организовать процессы управления жизненным циклом отдельных документов, а также эффективно разграничить права доступа к некоторым разделам (например, документам, описывающим применяемые средства защиты информации) при сохранении целостности и единства описания.
Наряду с описанием элементов инфраструктуры в ходе разработки документа определяется реализация применительно к конкретным особенностям предприятия процессов поддержки жизненного цикла ИТ-архитектуры. К этим процессам относятся, в частности:
• документирование, рецензирование, информирование, изменение;
• проверка соответствия, поддержка актуальности;
• организация управления разработкой.
Метод Захмана
Метод Захмана является одной из ранних попыток связать характеристики информационной системы с бизнес-задачами предприятия. Ни одна современная организация не работает без системы или систем какого-либо рода, при помощи которых достигаются цели функционирования этой организации. Информационная система – это комбинация «ручных» и компьютерных процессов, решающих поставленные задачи, четко и логично взаимодействующих между собой. В условиях современной конкурентной экономики использование развитых информационных систем помогает организациям занимать лидирующие позиции в бизнесе.
Этот метод хорошо известен в мировой практике. Суть его сводится к формализованному представлению модели предприятия в виде матрицы. В строках этой матрицы отображаются различные категории специалистов, определенным образом связанных с деятельностью предприятия (планировщик, собственник предприятия, проектировщик, разработчик и субподрядчик), а в столбцах – основные аспекты производственной деятельности (объекты = что, действия = как, местоположения = где, люди = кто, время = когда и мотивы = почему). Структура матрицы изображена на рис. 7.3.
Рис 7.3. Формализованное представление модели предприятия по методу Захмана
На рис. 7.4 изображена диаграмма, иллюстрирующая несколько главных технологий моделирования, а также места их пересечения при формировании матрицы Захмана. Каждая из этих моделей реального мира должна соответствовать контексту общего направления бизнеса, которое определяется его задачами, приоритетами и критическими для успеха факторами.
Рис. 7.4. Типы моделированияИспользование моделей (рис. 7.5) на разных стадиях развития системы проиллюстрировано в табл. 7.1.
Рис. 7.5. Модели развития системыТаблица 7.1. Использование методов моделирования
Примечание к табл.:
о – обязательное использование;
н – не обязательное, но возможное использование.
В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Такая схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем в разрезе трех выбранных аспектов, к которым относятся данные, функции и сетевая структура. В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками (рис. 7.5).
Архитектурное представление – это ячейка таблицы, соответствующая пересечению выбранных столбца и строки. Захман определяет архитектуру как представление информационной системы с точки зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем вы являетесь и на каком аспекте фокусируете внимание, вы видите архитектуру системы по-разному.
Заказчик видит систему с точки зрения общих стратегических и тактических аспектов. Они могут находиться в очень широких диапазонах (бизнес в целом или, напротив, его часть) и не всегда могут быть определены точно. Архитектурные представления, соответствующие точке зрения заказчика, приведены в двух верхних строках таблицы. Начальное планирование бизнеса и анализ обычно определяют первые уровни детализации для этих архитектурных представлений. Цели бизнеса и его требования к системе полностью детализируют каждое представление.
Представления проектировщика, несмотря на то что рассматривается одна и та же система, существенно отличаются от представлений заказчика, причем не только дополнительными деталями. Представления проектировщика – это проект системы, обеспечивающей удовлетворение требований, которые, в свою очередь, описываются представлениями заказчика. Во многом представление проектировщика добавляет точность, необходимую для тех, кто будет реализовывать систему, но представления проектировщика и заказчика остаются независимыми от технологий, которые будут использоваться при реализации. Структурный анализ, информационное моделирование и отдельные виды прототипирования являются теми методами, которые могут быть использованы для формирования архитектурного представления проектировщика. Точке зрения проектировщика соответствует третья строка в схеме Захмана.
Проекты, связанные с созданием систем, наиболее успешны, когда компоненты каждого из технологически независимых взглядов, соответствующие данным, функциям и сетевой структуре (три верхних строки), разрабатываются одновременно командой, хорошо понимающей бизнес и имеющей опыт в создании приложений и сетей, а также в администрировании данных. Хотя участники могут представлять свою точку зрения (заказчик или проектировщик) или фокусироваться на своих аспектах (данные, функции или сети), каждый вносит свой набор знаний. Эти наборы в совокупности дают хорошую общую картину требуемой системы. В достаточной степени проектировщики должны понимать точку зрения заказчика и наоборот. Заказчик и проектировщик не могут развивать свои взгляды отдельно друг от друга. Физическое воплощение логических требований зависит от характеристик аппаратно-программной базы, выбранной для реализации системы. В отличие от желаемых логических связей, реальные связи зависят от физических ограничений. Таким образом, необходимо знать, что мы хотим, перед тем, как делать вывод о невозможности чего-либо. Технология ограничивает решения задач, а не их условия.
Важно помнить, что строки схемы представляют разные точки зрения, а не разные уровни детальности представления. Для каждой ячейки таблицы может быть сделано многоуровневое описание. Необходимо понимать, что могут возникать ситуации, в которых важно понятие взгляда, то есть совокупности архитектурных представлений, находящихся в пределах одной строки.
Три аспекта, рассмотренных в схеме, приводят к различным архитектурным представлениям каждой из точек зрения. Аспекты соответствуют вопросам «Что?», «Как?» и «Где?», относящимся к конечному продукту (информационной системе). Каждому аспекту соответствуют разные методы формирования представления.
Колонка данных соответствует вопросу «Что?». В строительстве, например, она соответствует списку материалов и частей, используемых при возведении здания, и взаимосвязям между этими частями. Внимание концентрируется не на том, из чего строится здание, а на том, как и где оно строится. Для информационных систем вопрос «Что?» относится к сущностям данных и их связям.
Колонка функций соответствует вопросу «Как?». Она описывает, как работают отдельные части системы. В информационных системах функции обычно определяются входами (элементы данных), процессами (преобразования) и выходами (элементы данных). Внимание уделяется не столько отдельным частям и их связям, сколько тому, как эти части взаимодействуют при выполнении общей задачи.
Колонка сетевой структуры соответствует вопросу «Где?». Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.
В целом схема Захмана является простым, но достаточно мощным средством создания приложений и других необходимых компонентов ИТ-инфраструктуры организации. Необходимо помнить, что эта схема была разработана достаточно давно и ее применение вместе с современными стандартами может вызвать трудности.