6. МЕТОДИКИ ОПИСАНИЯ АРХИТЕКТУР

6.1. Модели жизненного цикла информационной системы

Существующие модели ЖЦ:

• Каскадная модель. Весь объем работ разбивается на этапы (рис.18). Переход на следующий этап разработки только после окончания работ на предыдущем этапе. Этап заканчивается формированием полного комплекта документов [28].

Рис. 18. Каскадная модель разработки

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

• Спиральная модель. Основное внимание направлено на начальные этапы ЖЦ: анализ требований к системе, спецификации, предварительное проектирование (рис.19). Технические решения, создаваемые на этих этапах, проверяются. Уточняются цели и характеристики проекта, уточняются детали. Каждый виток спирали создает свою версию системы. Далее работа уточняется, углубляются и поэтапно конкретизируются детали проекта. В итоге выбирается наиболее приемлемый вариант системы, который доводится до реализации [28].

Рис. 19. Спиральная модель жизненного цикла системы

6.2. Модель Захмана
IT-архитектура компании –единое описание важнейших направлений организации, которые имеют связь с информационной средой, прикладными системами и технологиями, при этом учитывается вoздействие на основные функции и процессы компании [14].
ИсследованиеIT-архитектуры компании несет в себе составляющие, связанные с мнoгoфункциональной архитектурой, IT-технологиями и управлением. IT-структура компании– целостное описание главных стратегий и целей организации, связанных с технологиями, прикладными системами и информацией. И с воздействием их на бизнес-функции и бизнес-процессы организации [6].
Рассмотрение IT-архитектуры компании производится в определенном контексте имеющихся в компании текстур управления и взаимодействия.
Есть разные модели и способы описания IT-архитектуры. Все эти способы задают классификацию главных областей и единичные взгляды для их описания. Существуют различные способы отображения примeняемых стереотипов, действий, моделей для oпределения разных частей IT-архитектуры, например [7]:

• методики аналитических компаний: Gartner, Giga, META и др.;
• модель Захмана;
• методика TOGAF;
• методика POSIX 1003.23i и др.

Методика – инструмент для создания широкого диапазона разнообразных архитектур [32]. Она включает в себя определение методов проектирования IT-структуры в понятиях использования определенных "строительных блоков", описание того, как эти "строительные блоки" связаны между собой, набор средств для определения частей архитектуры. Методики включают в себя список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для воплощения разнообразных частей структуры. Методики конкретизируют, как все эти элементы описания связаны между собой[26]. Определены индустриальные стандарты, чтобы описать ИТ-архитектуру предприятия. Отдельно друг от друга эти стандарты не могут дать разработчикам IT-архитектуры полного набора незаменимых инструментов с точки зрения этой методики и с точки зрения стандартов, которые нужны, чтобы описать архитектуру.
Отображение IT-архитектуры служит детальным руководством, определяющим первоначальные, стандартные или типовые элементы IT-систем, взаимодействие между собой, а также процессы управления информационными системами. Можно сформулировать такие требования [26]:

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

Для правильного описания IT-архитектуры организации могут применять разные форматы. Принципиально, чтоб организация употребляла такой формат описания, который бы давал простой для понимания метод руководства по развитию всех качеств IТ в компании [35].
Почти все термины IT-архитектуры считаются произошедшими от  единых понятий, относящихся к архитектуре компании в целом. Поэтому для описания и прогнозирования IT-архитектуры используются инструментальные и методологические средства моделирования, созданные для наиболее обобщенных задач.
Схема Захмана [4, 11] основывается на предмете традиционной архитектуры и формирует единый словарь и набор возможностей или структур для описания основных усложненных корпоративных систем. В собственном труде Дж. Захман обозначил архитектуру компании как "набор описательных моделей, применимых для описания предприятия в соответствии с требованиями управленческого персонала, которые могут развиваться в течение определенного периода". Понятие "архитектура" не случайно, оно выделяет существующую аналогию между внутренней текстурой теоретического объекта – компанией, и сложным искусственным объектом, таким, как башня либо аэродром.
Модель архитектуры, которую предложил Захман, преследует две главные цели [4, 11]:
 - с одной стороны, упорядочить описание архитектуры, разбив ее на отдельные сегменты для лучшего восприятия и возможности анализа;
 -с другой – иметь возможность рассмотрения всей архитектуры с интересующих точек.
До этого широко употребляемым подходом при описании системы использовалось понятие жизненного цикла системы, которое содержало рассмотрение таких этапов, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов анализируются  и основные функции системы, и данные.
Ученый внес предложение вместо стандартного подхода, опирающегося на рассмотрение отдельных аспектов работы системы как бы в разные факторы времени, рассматривать системы с разных точек зрения [4, 11].
Первоначально модель Захмана была оформлена конкретно для IT-систем. Данный подход в следующем труде ученого был обобщен для рассмотрения и для описания компании в целом. Поэтому можно считать рассматриваемую модель пригодной для описания архитектур производственных систем различной сложности, вне зависимости от типа.
Главная мысль заключается в том, чтобы обеспечить возможность поочередного описания каждого отдельного аспекта системы в связи со всеми остальными. Связать характеристики системы с задачами в области бизнеса. В основе лежит то правило, что ни одна система не достигает цели функционирования в области бизнеса без использования какой-либо пригодной для этих целей системы. А информационная система состоит из процессов, которые выполняют люди, и процессов, которые выполняют компьютеры.
Модель предприятия задается в виде матрицы (рис. 20). Фактически модель изображается в виде таблицы, имеющей 5 строчек и 6 столбцов. Именно модель, которая соответствует уровню описания архитектуры, содержит точно 5 строк. Строки отражают категории специалистов, которые участвуют в деятельности предприятия. Столбцы отражают основные аспекты производственной деятельности. Шестая строка в данной модели соответствует уровню работающей системы.
Две верхние строчки отображают наиболее общие представления и довольно обширно поясняют имеющееся окружение, намерения и цели. Если провести аналогию со строительством, то данные значения несут в себе сведения о местоположении и функции возведенного сооружения, а также намерения и изображения, которые конструктор обговаривает с владельцем строящегося здания. Следующий этап "логической модели" считается наиболее определенным, однако всё ещё довольно отвлеченным. Наверное, это схемы, которые архитектор этого здания обязан демонстрировать поставщикам и заказчикам.

Рис. 20. Модель Захмана

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

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

Основные правила при заполнении таблицы:

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

Участники могут фокусировать свое внимание на различных деталях, рассматривать разные вопросы, но в итоге должно сформироваться общее видение архитектуры, отражающее реальную картину. Проектировщик должен понимать точку зрения заказчика и наоборот. Строки представляют разные точки зрения.
Предложенная модель архитектуры является простым, однако очень значимым инструментом для организации и планирования работ по созданию и применению информационных систем, основанным на системном подходе. Модель архитектуры дает концентрацию на частных аспектах системы и в то же время не утрачивает чувство всеобщего контекста, т.е. взгляда на компанию в целом.
Диаграмма на рис. 21 иллюстрирует несколько методов моделирования [31]. Пересечение методов используется для формирования матрицы Захмана.
В табл. 6 приведено, какие модели на каких стадиях описания систем рекомендуется использовать.

 

 

 

Рис. 21. Методы моделирования
Таблица 6
Модели развития систем

Модели	Данные	Функции	Работы
Цели, масштаб проекта	Список того, что важно для бизнеса	Список процессов бизнеса	Список областей бизнеса
Модель бизнеса	Диаграммы «сущность-связь»	Диаграммы потоков данных	Связь работ
Модель информационной системы	Модель данных	Иерархия функций	Модель архитектуры системы
Технологическая модель	Проектирование данных	Модель организационных единиц	Оборудование, программное обеспечение
Детальное представление	Полное описание модели данных	Описание программ	Схемы адресаций и используемых протоколов
Функционирова-ние системы	Данные	Функции	Связи

Джон Захман предложил использование методов моделирования для различных уровней описания архитектуры [4] (табл. 7).

Таблица 7
Использование методов моделирования

Методы	Уровень бизнеса	Системный уровень	Программный/ Процедурный уровень
Функциональная иерархия	о	о	о
Анализ состояния	н	о	н
Диаграммы потоков данных	н	о	н
Событийное моделирование	н	о	о
Функциональная логика	о	о	н

О – обязательное использование
Н – необязательное использование

6.3. Cтруктура и модель описания ИТ-архитектуры Gartner

Рассмотрим подходы к описанию архитектуры предприятия, предложенные Gartner [41].
Одной из простых форм описания архитектуры является задание компонент в виде матриц. В матрице задаются компоненты архитектуры ИТ. Это могут быть данные, приложения, интеграция, общие сервисы и инфраструктура. Каждая компонента архитектуры ИТ имеет несколько спецификаций, которые отличаются уровнем детализации и конкретизации [25].
Такой подход позволяет делать стоимостную оценку и устанавливать зависимости между выбранными технологиями и их значимостью для бизнеса.
Для IT-проектов стилями бизнес-процессов являются [7]:
- массовая обработка транзакций;
- операции в реальном масштабе времени;
- аналитические процессы и бизнес-анализ;
- общая работа.
В 2002 г. Gartner определила концепцию архитектуры предприятия. Модель Gartner расширяет представления, а также акцентирует внимание на связь между совокупностью электронных процессов, при помощи которых организация воспринимает внешнее окружение, и реализацией этих идей на практике, с использованием современные подходов.
Модель Gartner 2002 г. представляет собой 4 взаимосвязанных уровня (рис. 22) [41]:

• Среда бизнес-взаимодействия;
• Бизнес-процессы и стили бизнес-процессов;
• Шаблоны;
• Технологические строительные блоки (кирпичики).

Рис.22. Уровни архитектуры Gartner

• Уровень «Среда бизнес-взаимодействия» описывает модель взаимодействия бизнеса и информационной среды, для которых будет разработана архитектура, согласно выявленным бизнес-процессам;
•  Уровень «Бизнес-процессы» описывает основные функции на предприятии;
• Уровень «Шаблоны» описывает, какие шаблоны могут быть использованы для задания модели;
• Уровень «Строительные блоки» расшифровывает содержание шаблонов и содержит соответствующие им элементы, такие как серверы, операционные системы, базы данных.

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

Рис. 23. Архитектура ИТ в бизнесе
6.4. Методика META Group
META Group-архитектура является некоторым структурированным описанием информационных технологий предприятия и его информационной технологией, алгоритмом создания и улучшения аспектов архитектуры группами работников, вовлеченных в этот процесс. Этим аспектам политика компании уделяет весомое внимание. При этом отличие методики META состоит в более детальном и точном описании разработки процесса архитектуры и всех её элементов [1].
Методика архитектуры META Group относится к таким понятиям, как архитектура технологии масштаба организации. Но позже, исходя из более тесного соприкосновения бизнеса и информационных технологий,  в поле деятельности META Group были добавлены такие элементы, как архитектура бизнеса, информационная архитектура и портфель систем организации. Это соответствует эволюции понятия "архитектура предприятия" [35].
Помимо всего этого, расширяя многие другие представления, архитектурная деятельность META  Group определяет архитектуру компании во взаимодействиях с другими основными процессами, а точнее, с процессом управления корпоративными ИТ-программами и проектами и процессом планирования. Понимается, что архитектура определяется на практике как процесс управления ИТ-программами и проектами [36].
Общим для всех аспектов META Group является задание бизнес-требований к ИТ-архитектуре. Это задание выводится с помощью двух документов: видения общих требований и концептуальной архитектуры [1].
Организация процесса работы архитектуры и оперативное создание начального продукта архитектуры предприятия, согласно методике META Group, состоит в выполнении трех этапов [1].
Этап 1 связан с выявлением основных задач (табл. 8):

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

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

Таблица 8

Пример 1-го этапа «Выявление основных задач»
Тенденция	Бизнес-стратегия предприятия	Требования к информационным системам	Требования к архитектуре
Ошибки при работе с данны-ми отнимают 15% времени на их исправление	Процесс работы, уменьшающий ошибки, привлечет больше клиентов	Информация об ошибках при рабо-те с данными  должна немедлен-но отображаться и предаваться администратору	ИТ - инфраструктура должна обеспечивать корректировку данных и своевременную выдачу информации, чтобы обеспечить операционную эффективность

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

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

Результатом работ этапа 1 будут следующие документы [1, 11]:

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

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

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

Каждый домен архитектуры технологий включает принципы, технологии, стандарты, лучшие практики, используемые доменами технологической архитектуры при обеспечении работы ИТ-систем.
На рис. 25 приведено описание доменов технологической архитектуры [10].

Рис. 25. Описания доменов технологической архитектуры

В итоге документ, который описывает домен технологической архитектуры, включает определенные компоненты, такие как [10]:

• Миссия домена: цели и задачи домена.
• Компоненты домена: технологии, включенные в домен.
• Принципы проектирования: задают правила, касающиеся использования технологий в домене. Задают обоснование правил и рассматривают последствия. Соответствия между требованиями к технологической архитектуре и принципами проектирования могут быть заданы в виде матрицы.
• Стандарты: технические стандарты, задающие требования к технологической архитектуре. Различают стратегические, переходные, устаревшие и исследовательские или новые стандарты.
• Лучшие практики: для данной технологической архитектуры содержат описание лучших практик.
• Конфигурации: содержат описание стандартных конфигураций, если благодаря им можно уменьшить стоимость и/или сложность системы.
• Несоответствия: между имеющимся состоянием домена технологической архитектуры и состоянием, которое является желательным.

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

• Домены архитектуры – первый уровень адаптируемости технологий [10]. Определяются места, которые используют излишние технологии. Определяются лишние продукты и конфигурации. Вместе с тем изыскивается возможность их многократного использования.
• Шаблоны – второй уровень адаптируемости технологий [5, 14]. Одинаковые конфигурации технологий используют для решения одинаковых задач.
• Сервисы – третий уровень адаптируемости технологий [29]. Обеспечивают совместимость интерфейсов прикладных систем и приложений.

Различают 4 группы сервисов:

• Базовые инфраструктурные сервисы [29]: общие, стандартные технологии, которые широко определяются в рамках всех ИТ-систем компании. Они ориентированы на специалистов по инфраструктуре.
• Общие инфраструктурные сервисы [29]: общие, совместно используемые технологии, которые не содержат готовой бизнес-логики, ориентированы на разработчиков и могут быть не полностью стандартизированы. Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил.
• Общие бизнес-сервисы [29]: используются в различных бизнес-процессах, содержат известную, заданную бизнес-логику.
• Прикладные бизнес-сервисы [29]: применяются для специальных бизнес-процессов, содержат бизнес-логику высокого уровня.

Получается технологическая модель предприятия (рис. 26) [29].

Рис. 26.Технологическая модель предприятия

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

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

Вопросы для самопроверки

• Назовите модели описания жизненного цикла информационных систем.
• Какие существуют методики описания IT-архитектуры?
• Назовите требования к отображению IT-архитектуры.
• На чем основывается схема Захмана? В чем отличие модели Захмана от стандартного подхода?
• Что представляет собой модель Захмана?
• Что обеспечивает подход Gartner при описании архитектуры предприятия?
• Что представляет собой модель Gartner?
• К каким понятиям относится методика архитектуры META Group?
• Является ли общим для всех аспектов архитектуры META Group определение бизнес-требований к ИТ-архитектуре? Почему?
• Из каких этапов состоит организация процесса работы архитектуры?
• Какие матрицы используются в методике META Group?
• Приведите структуру описания доменов технологической архитектуры.
• Какие компоненты включает документ, который описывает домен технологической архитектуры?
• Назовите уровни адаптируемости технологий предприятия.
• Приведите технологическую модель предприятия.