Архитектура предприятия.

 

Лекция 5.

 

Тема лекции: «Архитектура инфраструктуры предприятия».

1.            Стратегия развития предприятия и проектирование архитектуры информационных систем.

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

3.            Адаптивная ИТ-инфраструктура.

 

1.    СТРАТЕГИЯ РАЗВИТИЯ ПРЕДПРИЯТИЯ И ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ИНФОРМАЦИОННЫХ СИСТЕМ.

 

1.1. Возрастание роли  ИТ-инфраструктуры в бизнесе.

 

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

 

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

 

Стабильная и надежная ИТ-инфраструктура очень важна.

 

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

 

На протяжении столетий «доверие» было основой нашей экономической системы. В экономических операциях мы полагаемся на «доверие», полагая, что все будет исполнено правильно. Наша уверенность основывается на нашем опыте взаимодействия и на репутации компаний, государственных ведомств и отдельных лиц. Многие службы, которыми мы пользуемся, теперь виртуализированы. Например, сумма денег на банковском счете — это не более чем запись в системе базы данных банка. В поддержку нашей деятельности создаются договоры, счета и квитанции. Но в мире, где продолжается рост автоматизации, даже такие документы имеют тенденцию виртуализироваться. Сколько компаний в наше время настаивают на том, чтобы клиенты принимали электронные счета к оплате, электронные договора и электронные отчеты вместо бумажных документов? Очень много! Пока они доступны клиентам, сохраняется некоторое убедительное свидетельство того, что система работает.

 

Роль инфраструктур компаний возрастает в связи с тем, что:

 

- бизнес — это локомотив для всего остального;

- для бизнеса необходимы информационно-коммуникационные технологии (ИКТ);

- без инфраструктуры не может быть ИКТ.

 

И как следствие:

 

Без инфраструктуры не может быть бизнеса.

 

Надежная инфраструктура — необходимое условие непрерывности и маневренности бизнеса.

 

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

 

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

 

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

 

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

 

Инфраструктура начала становиться «интеллектуальной» параллельно с массовым появлением решений в области связи и взаимодействия систем. Это совпало по времени с бурным развитием и развертыванием приложений нового типа (таких как электронный маркетинг, электронная коммерция, планирование ресурсов предприятия [ERP] и организация информационных хранилищ), для которых требовались новые инфраструктурные службы.

 

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

 

Почему архитектура инфраструктуры имеет решающее значение?

 

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

 

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

 

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

 

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

- Лучшее понимание и представление существующих комплексных инфраструктурных служб благодаря прозрачной и структурированной таксономии.

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

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

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

- Улучшенная согласованность с эксплуатационными службами благодаря тому, что архитектура позволяет основывать проектирование на соглашениях об уровне обслуживания (SLA — service level agreement)/соглашениях об эксплуатационном уровне (OLA — operating level agreement). Соглашения об уровне обслуживания и эксплуатационные службы играют важную роль на ранней стадии создания новых инфраструктурных служб. Благодаря этому улучшаются и более эффективно поддерживаются соглашения SLA и OLA. В сочетании со стандартизацией и консолидацией это снижает сложность управления уровнем обслуживания, а также эксплуатационных служб, поскольку в соглашениях SLA и OLA меньше расхождений.

 

1.2. Анализ существующего состояния развития ИТ на предприятии.

 

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

 

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

 

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

 

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

 

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

 

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

 

Обычно выделяют следующие этапы разработки информационных систем:

 

− выявление требований;

 

− философия развития ИТ в организации, в том числе место ИТ-подразделений в общей структуре;

 

− требования к ИТ с позиций стратегии развития организации;

 

− базовые принципы и направления развития ИТ;

 

− основные направления совершенствования процессов управления ИТ;

 

− интегральные характеристики ИТ-бюджета и списка проектов, необходимых для реализации ИТ-стратегии;

 

− показатели оценки качества и целевые показатели работы ИТ-системы;

 

− возможные риски и альтернативные варианты развития ИТ.

 

− разработка;

 

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

 

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

 

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

 

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

 

 

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

 

Для того чтобы ИТ-стратегия соответствовала общей стратегии, в ней должны быть определены:

 

− философия развития ИТ в организации, в том числе место ИТ-подразделений в общей структуре;

 

− требования к ИТ с позиций стратегии развития организации;

 

− базовые принципы и направления развития ИТ;

 

− основные направления совершенствования процессов управления ИТ;

 

− интегральные характеристики ИТ-бюджета и списка проектов, необходимых для реализации ИТ-стратегии;

 

− показатели оценки качества и целевые показатели работы ИТ-системы;

 

− возможные риски и альтернативные варианты развития ИТ.

 

Важно подчеркнуть, что базовые принципы и направления развития ИТ должны быть детализированы до начала внедрения программных продуктов и информационных систем,  например, :

 

- внедрение комплексного продукта (например, системы класса ERP II) и автоматизация на его основе всех бизнес-процессов;

 

− внедрение нескольких специализированных продуктов, каждый из которых решает отдельный класс задач, и создание единой системы посредством интеграции этих продуктов;

 

− автоматизация отдельных участков (или бизнес-процессов) посредством внедрения отдельных модулей, входящих в один или в разные продукты;

 

− проведение заказной разработки одной из подсистем и интеграция её с другими продуктами в единую информационную систему;

 

− осуществление комплексной разработки информационной системы организации (предприятия).

 

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

 

В частности следует отразить следующие позиции:

 

− комплексность автоматизации;

 

− если не предполагается комплексная автоматизация, то определение направлений деятельности, бизнес-процессов или подразделений, которые будут информатизироваться;

 

− порядок процесса информатизации, сроки отдельных этапов;

 

− выбор используемых продуктов, систем, платформ;

 

− применение заказных разработок;

 

− используемые методики интеграции информационных систем;

 

− способы реализации проектов (использование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.);

 

− способы поддержки основных ИТ-сервисов (традиционный, SLA).

 

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

 

1.3. Состав работ по разработке ИТ-стратегии и ИТ-архитектуры.

 

Определение архитектуры предприятия дано и в стандарте ANSI/IEEE Std 1471-2000: «фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие».

 

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

 

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

 

Эта взаимосвязь адекватна взаимосвязи между общей стратегией развития предприятия и архитектурой предприятия. Стратегия имеет более общий характер, не так детально рассматривает отдельные аспекты, как архитектура. Но, в отличие от архитектуры, стратегия продолжительна во времени. На оси времени архитектура отражает конкретный момент, а стратегия – период. Можно сказать, что стратегия описывает последовательность преобразования архитектуры во времени. При этом каждая конкретная архитектура в этой последовательности рассматривается не детально, а в общих чертах.

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

 

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

 

Состав работ по разработке собственно ИТ-стратегии:

 

− разработка философии развития ИТ в компании и определение места ИТ-подразделений в структуре предприятия;

 

− разработка требований к ИТ с позиций бизнес-стратегии;

 

− разработка оценок качества и целевых показателей работы ИТ-системы;

 

− определение альтернативных вариантов развития ИТ и анализ возможных рисков;

 

− определение базовых принципов и направлений развития ИТ;

 

− определение основных направлений совершенствования процессов управления ИТ;

 

− определение интегральных характеристик ИТ-бюджета;

 

− определение списка проектов, необходимых для реализации ИТ-стратегии, их последовательности и сроков;

 

− определение типовых способов реализации проектов (использование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.);

 

− определение способов (традиционный, SLA); поддержки основных ИТ-сервисов

 

− эскизная разработка ИТ-архитектуры на ближайшую перспективу, включая архитектуру приложений и технологическую архитектуру;

 

− эскизная разработка ИТ-архитектуры на долгосрочную перспективу, включая архитектуру приложений и технологическую архитектуру.

 

2. КОНТЕКСТ И ОСНОВНЫЕ ЭЛЕМЕНТЫ ТЕХНОЛОГИЧЕСКОЙ АРХИТЕКТУРЫ.

 

2.1.               Понятие технологической архитектуры.

2.1.

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

 

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

 

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

 

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

 

Технологическая  архитектура включает в себя следующие компоненты:

 

− СЕТЕВУЮ АРХИТЕКТУРУ;

 

− АРХИТЕКТУРУ ХРАНЕНИЯ;

 

− АРХИТЕКТУРУ ИНФРАСТРУКТУРЫ ПРИЛОЖЕНИЙ;

 

− АРХИТЕКТУРУ УПРАВЛЕНИЯ;

 

− АРХИТЕКТУРУ БЕЗОПАСНОСТИ.

 

2.2.                Разработка технологической архитектуры.

 

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

 

Существуют различные способы категоризации технологий и сервисов, которые относятся к технологической архитектуре.

 

Например, META Group выделяет два различных типа областей (доменов) технологической архитектуры:

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

2)   прикладные (более специфические с точки зрения использования бизнесом).

 

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

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

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

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

 

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

 

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

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

 

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

 

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

 

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

 

Эта справочная модель содержит четыре области технологических сервисов:

1)   доступ и доставка;

2)   платформы и инфраструктура;

3)   компонентная модель;

4)   сервис интерфейсов и интеграции.

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

 

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

 

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

 

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

 

ТЕХНОЛОГИЧЕСКАЯ АРХИТЕКТУРА ЯВЛЯЕТСЯ АРХИТЕКТУРОЙ ИНФРАСТРУКТУРЫ АППАРАТНОГО И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, КОТОРАЯ ОБЕСПЕЧИВАЕТ РАБОТУ ПРИКЛАДНЫХ СИСТЕМ И ВЫПОЛНЕНИЕ ОПЕРАЦИОННЫХ (НЕФУНКЦИОНАЛЬНЫХ) ТРЕБОВАНИЙ, ПРЕДЪЯВЛЯЕМЫХ К АРХИТЕКТУРЕ ПРИКЛАДНЫХ СИСТЕМ И ИНФОРМАЦИИ.

 

ОНА ОПИСЫВАЕТ СТРУКТУРУ И ВЗАИМОСВЯЗИ МЕЖДУ ИСПОЛЬЗУЕМЫМИ ТЕХНОЛОГИЯМИ И ТО, КАК ЭТИ ТЕХНОЛОГИИ ОБЕСПЕЧИВАЮТ ВЫПОЛНЕНИЕ ОПЕРАЦИОННЫХ ТРЕБОВАНИЙ ОРГАНИЗАЦИИ.

 

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

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

с архитектурой приложений и технологической архитектурой.

 

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

 

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

 

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

 

Он основан на использовании двух критериев:

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

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

 

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

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

 

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

 

3. АДАПТИВНАЯ ТЕХНОЛОГИЧЕСКАЯ ИНФРАСТРУКТУРА.

 

3.1.       Понятие адаптивной инфраструктуры.

 

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

 

Основными характеристиками адаптивной системы  являются:

 

1)   самоконфигурирование – организация системы в соответствии с требованиями;

2)   самозащита – предотвращение сбоев в системе в результате нарушения работы компонент системы и потери целостности данных;

3)   самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий;

4)   самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора.

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

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

 

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

«лезвия», так и специализированное программное обеспечение для «оркестровки» существующих ресурсов.

 

Существует несколько концептуальных обоснований для таких решений. Одним из них является так называемая концепция «Organic IT», предложенная компанией Forrester.

 

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

 

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

 

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

 

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

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

 

3.2.               Роль стандартов.

 

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

 

С другой стороны, можно выделять два класса – «технологические» и «рамочные» стандарты.

 

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

 

Для наших задач, связанных с разработкой архитектуры предприятия, наибольший интерес будут представлять такие «рамочные» стандарты, как уже упоминавшийся ISO 15704, а также ISO 15288 и, частично, ISO 12207.

 

Помимо указанных, при разработке архитектуры предприятия достаточно широко используется порядка 30-ти дополнительных «поддерживающих» стандартов системной и программной инженерии. Например, стандарт ISO 14258 определяет концепции и правила для моделирования Предприятия и т.п. Эти стандарты являются рамочными (Framework) в том плане, что они задают общие требования к реализации процессов, связанных с разработкой и поддержкой жизненного цикла систем. Они обычно используются как методологическая основа для организации этих процессов с необходимой конкретизацией для каждого данного предприятия или области деятельности.

 

Если стандарт ISO 12207 был разработан для определения жизненного цикла только программного обеспечения, то ISO/IEC 15288 определяет жизненный цикл «более общей» системы. В применении к нашему контексту такой системой может являться совокупность информационных систем предприятия в целом.

 

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

 

Как уже отмечалось, профили могут создаваться как для отдельной системы, так и для класса систем, предназначенных для использования в определенных рамках. Хорошим примером такого профиля является SAGA, описывающая требования к системам для реализации «электронного правительства» в Германии.

 

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

 

При этом сами профили можно условно разделить на два класса:

 

1. Профили, описывающие собственно программные или архитектурные решения  на основе ISO 15288; и
2. Профили, регламентирующие процессы жизненного цикла программных систем, такие как разработка, тестирование, сопровождение и т.п. Обычно для этого класса за основу берется стандарт ISO 12207.

 

Важным преимуществом использования архитектурных профилей является ориентация на использование модели открытых систем. Основные рекомендации по разработке таких профилей окружения открытых систем приведены в документе IEEE 1003.23, доступном по адресу http://www.enterprise-architecture.info.

 

Создаваемые профили могут быть использованы как для детализации собственно ИТ-архитектуры, так и для формализации процесса ее разработки.

 

Обычно в состав такого профиля включаются следующие разделы:

1. Требования со стороны бизнеса, функциональной архитектуры, конечных пользователей, управления информационной системой;
2. Применяемые формальные, перспективные и де-факто стандарты;
3. Стратегии и планы миграции.

 

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

 

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

 

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

 

3.3.  Инфраструктурные шаблоны.

 

Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин «pattern» имеет различные варианты перевода, в том числе «образец», «шаблон» и т.п. В данном случае мы будем использовать русский термин «шаблон», оставляя кальку «паттерн» для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы.

 

Одним из удачных определений шаблонов является следующее: «ШАБЛОН – ЭТО ОБЩЕЕ РЕШЕНИЕ НЕКОТОРОЙ ПОВТОРЯЮЩЕЙСЯ ПРОБЛЕМЫ В ОПРЕДЕЛЕННОМ КОНТЕКСТЕ» (рисунок 3).

 

Рисунок 3. Шаблон – решение проблемы в контексте.

 

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

 

Осознание важности шаблонов привело к тому, что, например, методика описания архитектуры Gartner выделяет шаблоны в качестве отдельного «слоя» архитектуры.

 

Использование шаблонов имеет явные корни в строительной архитектуре. Определяющий вклад в формирование исходного понятия «pattern» принадлежит известному архитектору Кристоферу Александеру. В своей фундаментальной работе 1987 года  он выделил более 250 типовых архитектурных решений, таких как лестницы, альковы, связи между офисами и др. Согласно Александеру, каждый такой прототип фактически определяет рекомендуемое решение отдельной проблемы в фиксированном контексте. В оригинале Александер выделяет контекст, воздействующие силы и особенности применения данного шаблона. В соответствии с аллегорическим комментарием Коупа, описание шаблона – это пьеса. Контекст задает место действия и определяет актеров, силы плетут заговор, найденное решение обеспечивает Катарсис.

 

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

 

В приведенном выше определении шаблона имеется три ключевых словосочетания:

 

ОБЩЕЕ РЕШЕНИЕ. Это означает, что шаблон не дает полного законченного решения. Он, скорее, определяет класс проблемы и то, как эта проблема может быть решена с использованием определенного подхода, с демонстрацией аргументов в пользу этого подхода. Сила шаблона состоит в том, что он сформулирован на достаточно высоком уровне абстракции, чтобы быть использованным в большом количестве ситуаций.

 

ПОВТОРЯЮЩАЯСЯ ПРОБЛЕМА. Это означает, что шаблоны используются в тех случаях, когда проблема не является уникальной, и они наиболее полезны для решения часто встречающихся проблем.

 

ОПРЕДЕЛЕННЫЙ КОНТЕКСТ. Это означает, что шаблон обеспечивает решение проблемы, границы которой в общих чертах определены. Понимая условия, в которых предлагаемое решение в форме шаблона является хорошим, вы далее строите свое собственное решение на основе этого шаблона.

 

В области информационных технологий первоначально шаблоны получили признание в области программной архитектуры. В широко известной работе группы авторов (которых в англоязычной литературе по числу авторов книги часто называют «бандой четырех») описаны типовые конструкции для объектно-ориентированных языков программирования, таких как C++. Большое количество ссылок по данной тематике и примеров приведены на http://www.patterns.com. Но оказывается, что понятие шаблона оказывается весьма эффективно и в области архитектуры предприятия в целом!

 

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

 

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

 

 

 

Рисунок 4. Шаблон показывает взаимодействие компонент системы между собой.

 

 

Важность шаблонов для архитектуры предприятия в целом обусловлена следующими причинами:

 

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

 

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

 

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

 

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

Рисунок 5. Архитектура, шаблоны и модели.

 

В рамках предприятия целесообразно создать репозиторий шаблонов. Характерное для предприятия число различных шаблонов составляет порядка 30. Это включает шаблоны использования унаследованных и старых клиент/серверных систем, модели для будущей архитектуры (например, сервис-ориентированной) и т.д.

 

Описание шаблонов может выполняться с различной степенью детализации и соответствия реальным условиям. В зависимости от этого уровня можно рассматривать элементы языка шаблонов различной степени абстракции – идиомы, шаблоны дизайна (design patterns) и рамочные модели (frameworks).

 

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

 

Шаблоны дизайна обладают определенной независимостью, но в то же время не могут рассматриваться как система в целом. Хорошим примером являются шаблоны стандартных классов. Например, понятие «Фабрики Объектов» в объектно-ориентированных приложениях, вообще говоря, не зависит от выбора конкретного языка программирования и может быть реализовано схожим образом и на С++, и на Java.

 

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

 

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

 

Типичными примерами являются шаблон B2B (Business-to-Business) для взаимодействия с Клиентами/Поставщиками или

 

B2E (Business-to-Employee), описывающий взаимодействие между информационной системой и сотрудниками.

 

ИНФРАСТРУКТУРНЫЕ ШАБЛОНЫ МОЖНО ОПРЕДЕЛИТЬ КАК СТАНДАРТИЗИРОВАННЫЙ НАБОР ТРЕБОВАНИЙ, КОМПОНЕНТ И СЕРВИСОВ, КОТОРЫЕ В СОВОКУПНОСТИ ФОРМИРУЮТ НЕОБХОДИМУЮ АДЕКВАТНУЮ ИНФРАСТРУКТУРУ ДЛЯ ДАННОЙ ПРИКЛАДНОЙ СИСТЕМЫ И РЕАЛИЗАЦИИ ЛОГИКИ БИЗНЕС-ПРОЦЕССОВ.

 

Рисунок 6 иллюстрирует общее определение инфраструктурного шаблона в форме многоуровневой классификации функций и примерного списка технологических компонент на каждом уровне.

Рисунок 6. Пример инфраструктурного шаблона.

 

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

 

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

Рисунок 7. От традиционной архитектуры – к архитектуре,

использующей инфраструктурные шаблоны.

 

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

 

При использовании системного подхода к документированию и управлению ИТ-архитектурой компания получает следующие преимущества:

 

− снижение общей стоимости владения ИТ (ТСО) в стратегической перспективе;

 

− сокращение избыточности функционала существующих информационных систем;

 

− прозрачность существующего «зоопарка» систем;

 

− решение проблемы «лоскутной» автоматизации;

 

− возможность унификации информационных систем и элементов ИТ-архитектуры через стандартизацию в области ИТ и внедрение корпоративных стандартов;

 

− возможность идентификации критичных элементов ИТ-архитектуры на основе их взаимосвязи с критичными бизнес-процессами;

 

− возможность анализа взаимовлияния элементов ИТ-архитектуры между собой, а также с бизнес-процессами.

 

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

 

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

 

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

[1] Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия.  –   М. Интернет Ун-т Информ. Технологий, 2005. – 504 с.

 

[2] Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. Учебник для вузов. 2-е изд., доп. – Горячая линия-Телеком М., 2014. –  210 с. 

[3] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

 

[4] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).

 

[5] Трутнев Д.Р.  Архитектуры информационных систем. Основы проектирования: Учебное пособие. – СПб.: НИУ ИТМО (Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики), 2012. – 66 с.