Технологическая архитектура, стандарты и шаблоны

Оценка состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии

Для оценки состояния технологической инфраструктуры предприятия в терминах, понятных бизнес-руководству, и с точки зрения потенциальных возможностей реализации различных бизнес-стратегий, можно использовать подход, предложенный Питером Кином (Peter Keen) [4.26]. Он основан на использовании двух критериев:

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

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

Рис. 7.4. Охват и функциональные возможности инфраструктуры

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

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

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

Адаптивная технологическая инфраструктура

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

Основными характеристиками адаптивной системы (см. также [4.27]) являются:

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

Другая важная проблема – необходимость повышения эффективности использования существующих вычислительных ресурсов. Действительно, типовая загрузка мейнфреймов составляла порядка 80%, сейчас же характерными значениями являются порядка 40% для RISC-серверов и всего лишь 15% для Intel/Windows серверов. Это является следствием достаточно распространенной практики "каждому приложению – свой сервер". Но если для небольших организаций такой подход еще, в принципе, допустим, учитывая относительную дешевизну серверов уровня рабочей группы, то при количестве приложений в несколько десятков управление становится слишком неудобным, сложность – избыточной, надежность – низкой, а совокупные затраты – неприемлемо большими.

Для решения этой задачи предложили свои решения практически все ведущие производители, включая HP (концепция Adaptive Enterprise, архитектура Darwin), IBM (On Demand), Sun (N1), Microsoft (Dynamic Systems Initiative) и другие. Важной частью этих решений является комплексность, использующая как возможности аппаратных платформ, включая разделяемые процессорные разделы, виртуальные дисковые массивы, серверы-"лезвия", так и специализированное программное обеспечение для "оркестровки" существующих ресурсов.

Существует несколько концептуальных обоснований для таких решений ([4.28]-[4.30]). Одним из них является так называемая концепция "Organic IT", предложенная компанией Forrester. В соответствии с определением, "...это инфраструктура, построенная из относительно дешевых компонентов с такой избыточностью, которая обеспечивает автоматическое разделение между всеми приложениями и администрирование корпоративных информационных ресурсов, в том числе программного обеспечения, процессоров, систем хранения данных и сетей". Такая инфраструктура позволяет повысить "коэффициент полезного использования" ресурсов, упростить интеграцию различных технологических компонент между собой и облегчить управляемость системы в целом.

Аналогичная концепция под названием "Инфраструктура реального времени" (Real-Time Infrastructure, RTI) была предложена Gartner. RTI представляет собой "разделяемую между участниками, бизнес-подразделениями или приложениями инфраструктуру информационных систем, в которой бизнес-политики и соглашения об уровнях услуг (SLA) определяют ее динамическую и адаптивную оптимизацию для сокращения затрат при увеличении гибкости и качества сервиса".

Таким образом, основные идеи адаптивной инфраструктуры таковы:

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

Возможная реализация такой адаптивной инфраструктуры на практике может осуществляться так, как показано на рис. 7.5.

Приведем несколько комментариев к данному рисунку:

• элементарными "строительными блоками" являются отдельные ресурсы – серверы и отдельные процессоры, виртуальные устройства хранения данных, сетевое оборудование, программные серверы приложений и СУБД;
• обеспечение требований бизнеса производится в рамках модели предоставления сервисов. Каждый сервис реализуется на основе нужной комбинации программных и аппаратных ресурсов, преимущественно в рамках многозвенной архитектуры (уровень СУБД – уровень приложений – презентационный уровень);
• специальная "интеллектуальная" компонента системы – управляющий модуль (IT governor) на основе мониторинга времени реакции сервисов на запросы, прогнозных и исторических значений потребностей приложений, наличия ошибок/выхода из строя элементов системы и т.п. отвечает за оптимальную "оркестровку" – переконфигурирование виртуальных серверов, запуск серверов приложений, управление пулами однородных устройств, изменение приоритетов выполняемых приложений. Эта же компонента будет обеспечивать функции биллинга для учета реально использованных ресурсов со стороны приложений.

Рис. 7.5. Инфраструктура реального времени

Предполагается, что этот подход позволит, за счет эффективного усреднения потребностей приложений, обеспечить повышение загрузки ресурсов примерно вдвое. Заметим, что практическая реализация такой архитектуры потребует и соответствующего изменения модели сервисов. Для этого компанией Gartner предложена специальная концепция IT Infrastructure Utility и модель зрелости Infrastructure Utility Maturity Model. Проведем опять же аналогии со строительством: этот подход соответствует общепринятой мировой (увы, не российской) практике оплаты коммунальных услуг – ведь потребителя, в конечном счете, интересует предоставляемая мощность, стоимость электроэнергии и гарантии поставщика по ее бесперебойному обеспечению, а не изношенность генерирующих установок, зарплата обслуживающего персонала и задолженность одних коммунальных служб перед другими.