Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF
Базовая Архитектура, в свою очередь, включает:
- набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
- набор элементарных архитектурных элементов, которые используются как "строительные блоки" при построении конкретных решений;
- база данных стандартов (Standards Information Base).
Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур (см рис. 8.10) входящих в общий континуум определений.
В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т.п.
Следующая степень детализации реализуется на уровне Отраслевой Архитектуры, которая добавляет специфичные для каждой индустрии модели данных, приложения, стандарты, бизнес-правила, а также, при необходимости, процедуры взаимодействия различных отраслевых систем между собой. Наконец, на последнем уровне Архитектуры Организации формируется архитектура ИТ-систем конкретного предприятия, учитывающая все его особенности, в том числе наличие унаследованных систем, планы и возможности реализации, организацию данных на физическом уровне и т.п.
В состав Эталонной Модели, в свою очередь, входит система (таксономия) общих служб, включающая такие службы, как Обмен и преобразование данных, Управление данными, Поддержка интернационализации, Службы Каталогов и т.п.
Для всех используемых в архитектуре служб, наряду с функциональным назначением, необходимо определить и уровень качества реализации, то есть такие характеристики как управляемость, гибкость, гарантированность, удобство использования и т.п. При этом следует учитывать, что некоторые службы являются в этом плане взаимозависимыми. Например, для обеспечения заданного качества службы интернационализации могут потребоваться специализированные компоненты службы разработки программного обеспечения для создания и тестирования соответствующих программных продуктов.
Архитектурные принципы представляют собой как бы фундаментальные "аксиомы", которые используются в качестве "отправных точек" как для оценки существующей системы, так и для разработки отдельных архитектурных решений. Вообще говоря, архитектурные принципы являются подмножеством более общего понятия ИТ-принципов, которые определяют основные аспекты всей деятельности, связанной с применением информационных технологий. ИТ-принципы, в свою очередь, являются детализацией еще "более общих" принципов, определяющих деятельность предприятия в целом.
В состав набора принципов могут входить обоснования для формирования системы требований или критериев оценки тех или иных решений. Например, такой принцип, как "минимизация числа поставщиков программного обеспечения", может быть в дальнейшем конкретизирован в зависимости от особенностей предприятия, как требование "единой СУБД для всех критичных для бизнеса приложений" или же как "использование той же СУБД, что и уже применяемая". Архитектурные принципы могут также использоваться для обоснования значимости самого понятия Архитектуры и необходимости ее разработки для бизнеса предприятия, а также для выбора вариантов реализации этого процесса.
Принципы являются взаимозависимыми и должны применяться в целостном наборе. "Хороший" набор принципов должен удовлетворять таким естественным критериям, как доступность для понимания, точность формулировок, полнота, последовательность и стабильность (не нужно путать с неизменяемостью!) Обычно число принципов не превышает 20, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые неработоспособны на практике.
Примерный набор принципов может включать, в частности, следующие:
Название | Содержание |
---|---|
Пример использования | Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации |
Максимальная польза | Решения в области ИТ принимаются исходя из максимума пользы для организации в целом |
Привлечение всех | Управление информацией есть дело каждого |
Непрерывность бизнеса | Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ |
Общее использование | Предпочтение должно отдаваться разработке или внедрению приложений, применимых в масштабах всего предприятия, а не отдельных его подразделений |
Соответствие законодательству | Управление ИТ не должно противоречить применяемому законодательству и принятым регламентам, однако это не есть препятствие к улучшению бизнес-процессов, влекущему за собой изменение этих регламентов |
Ответственность ИТ-службы | ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса |
Защита интеллектуальной собственности | Обеспечение защиты интеллектуальной собственности организации должно быть реализовано на уровне архитектуры, процессов эксплуатации и управления ИТ |
Данные являются активом | Данные в ИТ-системе предприятия имеют определенную ценность и должны соответственно управляться, быть общими и доступными для пользователей с учетом их прав доступа |
Обеспечение качества | Каждый элемент данных должен иметь ответственного за качество |
Общие метаданные | Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей |
Безопасность данных | Данные должны быть защищены от неавторизованного использования и распространения |
Технологическая независимость | Прикладное ПО не должно зависеть от специфичных моделей оборудования и системного ПО |
Простота использования | Приложения позволяют сконцентрироваться на выполнении бизнес-задач за счет единого интерфейса, минимизации специфики работы, интеграции систем, снижения вероятности неправильного использования |
Обоснованность и своевременность изменений | Изменения в информационной системе и приложениях производятся только в соответствии с запросами бизнеса, но в случае появления такой необходимости – в нужное время |
Взаимодействие | Компоненты программного и аппаратного обеспечения должны обеспечивать интеграцию между собой в соответствии с общими стандартами |
Минимизация разнообразия | Уменьшение числа различных вариантов применяемых платформ, продуктов и версий |
Более подробную информацию о TOGAF можно найти по адресу http://www.opengroup.org/togaf.