Базовая Архитектура (Foundation Architecture)

Базовая Архитектура, включает в себя:

•набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);

•набор элементарных архитектурных элементов, которые используются как «строительные блоки» при построении конкретных решений;

•база данных стандартов (Standards Information Base).

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

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

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

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

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

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

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

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

Рисунок: Архитектуры Предприятия «TOGAF»

Примеры принципов, используемых при создании архитектуры TOGAF (Название и содержание):

•Пример использования – Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации.

•Максимальная польза – Решения в области ИТ принимаются исходя из максимума пользы для организации в целом.

•Привлечение всех – Управление информацией есть дело каждого.

•Непрерывность бизнеса – Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ.

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

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

•Ответственность ИТ-службы – ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса.

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

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

•Обеспечение качества – Каждый элемент данных должен иметь ответственного за качество.

•Общие метаданные – Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей.

•Безопасность данных – Данные должны быть защищены от неавторизованного использования и распространения.

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

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

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

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

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

Данный текст является ознакомительным фрагментом.