Контекст и основные элементы технологической архитектуры

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

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

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

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

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

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

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

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

Реальные преимущества от наличия упорядоченного в рамках технологической архитектуры списка используемых технологий таковы:

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

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

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

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

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

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

Рис. 7.1. Различные уровни размещения инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке 7.2 приведен пример областей, категорий, стандартов и спецификаций TRM FEAF.

Рис. 7.2. Пример областей, категорий, стандартов и спецификаций технической справочной модели TRM FEAF

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

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

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

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

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

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

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

Дата добавления: 2015-04-25