ИТ-архитектура. Практическое руководство от А до Я. Первое издание - читать онлайн

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

Определение Структуры Предприятия

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

Структура организации – фиксированное упорядоченное множество объектов и связей между ними.

По характеру специализации и видам деятельности различают:

Вертикальное разделение – по уровню подчинения

Горизонтальное разделение – по функциям и специфики деятельности

Соответственно в структуре управления различают линейные связи по типу «начальник – подчинённый» и функциональные «профессиональная интеграция на основе специфики деятельности». Как результат, тип структуры организации можно представить, как следующие основные типы и их разновидности:

Плоская – наиболее простая структура. Подходит для рабочих или проектных групп, или небольшой организации.

Иерархическая (бюрократическая) – формирование структуры исходя из структуры организации, разделение труда на функции и ответственности работников.

Линейная – управление по прямой (руководитель – подчинённый), общение между подразделениями только через руководителей подразделений

Функциональная – взаимодействие идет по функциональному признаку

Линейно-функциональная – взаимодействие совмещается по линейному и функциональному типу (наиболее используемая модель)

Линейно-штабная – отдельные функциональные группы (штабы), самостоятельно ведущие работу с подразделениями или организациями. Как пример группа компаний в составе холдинга.

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

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

Проектные – организуется при ведении проектов

Матричные (программно-целевые) – принцип двойного подчинения, непосредственное подчинения руководителю, и проектному менеджеру

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

Существование той или иной организационной структуры может зависеть от ряда факторов:

•Специфика и степень разнообразия деятельности

•Географическое размещение

•Уровень централизации в организации

•Стратегия организации

•Количества и спектра предоставляемых услуг

Определение роли ИТ в составе организации

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

Для понимания роли ИТ в конкретной организации нужно ответить на следующие вопросы:

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

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

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

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

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

Выстраивание взаимоотношения между бизнесом и ИТ

Сфокусировать действия ИТ на целях и задачах бизнеса. Бизнес и ИТ стороны по-разному видят задачи, цели и ожидания по отношению друг к другу. Видение ИТ сотрудников «… мы прекрасно разбираемся в технологиях, нам платят деньги за умение программировать, настраивать, устанавливать и решать технические проблемы и т п. Наша работа начинается после получения технического задание…». Видение со стороны бизнеса – «… столько новых ИТ технологий, ИТ должен нам внедрить нам какое-то решение, чтобы увеличить объем продаж. Или что еще хуже, нам нужно решение ХХХ, оно есть у конкурентов и поэтому продажи у них выше… внедряйте мы уже все решили вы ничего не понимаете бизнесе…». Задача ИТ директора, участие на равных в обсуждении стратегии бизнеса. Общие принцип можно определить, как: «бизнес описывает свои требования и ожидания (Бизнес требования), ИТ в свою очередь формирует техническое задание для достижения целей.»

Наладить сотрудничество между бизнесом и ИТ.

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

Получить максимальную ценность от ИТ.

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

ЦЕННОСТЬ = ВЫГОДА – ЗВТРАТЫ

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

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

Перенос часть работ на сторону ИТ департамента, или отказ от автоматизации ряда элементов, может снизить стоимость решения, повысить простоту эксплуатации и удобство для клиентов.

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

Управлять изменениями.

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

Навести порядок и управлять развитием ИТ.

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

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

•Обзор бизнес – архитектуры

•Описание существующей системы с необходимой степенью детализации

•Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре

•Разработка черновика технического отчета

•Направление черновика отчета на рецензирование

TOGAF позиционируется не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. Рассмотрим построение Архитектуры Предприятия на основе методологии «TOGAF» более детально, который на мой взгляд имеет ряд преимуществ:

•Подход TOGAF позволяет построить весь архитектурный процесс – от запуска практики до результатов.

•TOGAF – это де-факто является стандартом. Имеется программа сертификации по TOGAF.

•TOGAF – абсолютно бесплатен. Множество открытых ресурсов, скачивайте и используйте.

•TOGAF содержит полный набор инструментов для создания и развития архитектурной практики в организации. Есть пошаговый процесс для разработки описания Архитектуры Предприятия и полный набор инструментов, шаблонов и т. д.

•TOGAF совместим с другими Фреймворками, например, с «Zahman Framework». Как архитектурный процесс модель TOGAF дополняет модель Захмана – которая, классифицируется как архитектурная таксономия. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

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

Методология TOGAF и инфраструктура Захмана хоть и объединены к категории «инфраструктур предприятия», но имеют отличия в своих принципах, структурах и компетенциях. TOGAF- представляет собой функциональную и динамичную инфраструктуру, которая включает руководящие принципы моделей процесса их использования. В то время как фреймворк Захмана представляет собой статичную структуру архитектуры, наиболее эффективна для применения анализа и метаанализа фреймворков инфраструктур. Несмотря на значительные отличия данных фреймворков их можно использовать совместно.

Базовые принципы

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

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

В состав модели TOGAF входят две основные компоненты:

•методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.

•Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML.

Описание TOGAF включает в себя 7 частей:

•Introduction. Cодержит высокоуровневое описание ключевых концепций Архитектуры в целом и TOGAF в частности.

•Architecture Development Method (ADM). Ключевая часть TOGAF, описывает пошаговую методику разработки Архитектуры Предприятия.

•ADM Guidelines and Techniques. Включает в себя описание правил и техник, которые используются в TOGAF ADM.

•Architecture Content Framework. Описывает подход к описанию Архитектуры Предприятия. Содержит метамодель архитектурных артефактов, структуру и описание типовых архитектурных артефактов.

•Enterprise Continuum & Tools. Описан подход к категоризации и хранению результатов архитектурных активностей.

•TOGAF Reference Models. Описание эталонных моделей, которые вы можете использовать в ваших проектах.

•Architecture Capability Framework. Подход к организации архитектурной практики в компании. Структура, процессы, роли, навыки и полномочия, требуемые для работы архитектурной практики в компании.

В качестве основных процессов построения Архитектуры Предприятия важно внедрить всего четыре ключевых процесса:

•Создания и развития Архитектуры Предприятия.

•Управления изменениями.

•Контроль реализации архитектурных решений.

•Управления практикой.

Метод Развития Архитектуры (Architecture Development Method ADM) TOGAF

В TOGAF процессы создания и развития, управления изменениями, контроля реализации архитектурных решений интегрированы в единый архитектурный цикл Метод Развития Архитектуры (Architecture Development Method ADM). Данный метод можно и нужно адаптировать под задачи вашей компании на всех уровнях разработки архитектуры. При этом, нет необходимости делать все возможные документы. Не нужно погружаться во все детали. На каждом этапе ADM предлагает готовый набор техник, инструментов, шаблонов и чек листов. Метод Развития Архитектуры (ADM) содержит десять фаз. Каждая фаза, в свою очередь разбивается на под-процессы (этапы), отдельные работы и так далее.

Например, фаза D включает следующие основные под-процессы:

Описание существующей технологической архитектуры.

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

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

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

•Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.

•Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.

Формирование целевой технологической архитектуры.

•Описание существующей системы в терминах TOGAF.

•Определение перспектив (представлений) архитектуры.

•Формирование модели целевой архитектуры.

•Определение ИТ-служб (сервисов).

•Подтверждение учета бизнес-требований.

•Определение архитектуры и используемых блоков (шаблонов).

•Проведение анализа расхождений (gap analysis).

Фазы и задачи Метода Развития Архитектуры

Предварительная фаза. Основные задачи:

•Создать архитектурную практику,

•подготовить компанию к запуску архитектурных проектов,

•заручиться поддержкой руководства,

•сформулировать архитектурные принципы,

•адаптировать методологию под цели и задачи компании

Фаза А – Видение архитектуры. Основные задачи:

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

•разработать «Устав проекта» и получить формальное подтверждение старта проекта.

Фаза B – Бизнес Архитектура. Основные задачи:

•Разработать архитектуру с описанием текущей и целевой архитектуры,

•Анализ расхождений

Фаза C – Архитектура Информационных Систем. Задачи:

•Разработать архитектуру с описанием текущей и целевой архитектуры,

•Анализ расхождений

Фаза D – Техническая Архитектура. Основные задачи:

•Разработать архитектуру с описанием текущей и целевой архитектуры,

•Анализ расхождений

Фаза Е – Возможности и решения. Основные задачи:

•Выполнить начальное планирование реализации задач проекта.

•Идентифицировать основные проекты внедрения и сгруппировать их в переходные архитектуры.

Фаза F – Планирование миграции. Основные задачи:

•Анализ затрат и рисков.

•Разработка детального плана внедрения и миграции.

Фаза G – Управление реализацией. Основные задачи:

•Архитектурный надзор за проектами внедрения.

•Подготовить архитектурные контракты.

•Обеспечить соответствие архитектуре результатов проектов внедрения.

Фаза H – Управление изменениями архитектуры. Задачи:

•Подготовится к следующему витку жизненного цикла архитектуры.

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

Управление требованиями. Основные задачи:

•На каждой фазе архитектурного проекта собираете и согласуете бизнес требования.

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

Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:

•Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия.

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

•Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс Управления Архитектурной Практикой

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

•Люди. Они основа любой деятельности в компании. Если люди не знают, не умеют, не используют, не участвуют, не делают, не хотят, то все остальное бесполезно. Забыли про людей – забудьте про результаты.

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

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

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

Рисунок: Управление Архитектурной Практикой «TOGAF»

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

•залезают в дебри теорий и исследований;

•выполняют бесполезную работу;

•долго готовятся к выполнению работы;

•изобретают велосипед;

•«оптимизируют» свою работу вместо её выполнения;

•излишне теоретизируют;

•ищут ответственных и виноватых;

•считают себя самыми умными;

•избегают неприятной работы.

Подход к управлению архитектурной практикой состоит из шести основных элементов:

Методология — это основной элемент подхода. Он определяет процессы компании для разработки, обновления и реализации Архитектуры Предприятия. Роли и их обязанности.

Артефакты — набор, шаблоны и правила заполнения документов, таблиц, схем, при помощи которых описана Архитектура Предприятия.

Стандарты — это стандарты (законы, правила) ведения бизнеса и ИТ, которые использует компания в своей работе. Это могут быть международные стандарты, российские стандарты, стандарты отрасли, региона, компании.

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

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

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

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

Ключевые документы и шаблоны методологии TOGAF

Для внедрения методологии TOGAF возникает вопрос какой минимальный набор документов необходим для ведения архитектурного проекта? Лишние документы – лишние затраты времени и денег. По исходя из собственного опыта и теории (при подготовке к сертификации), минимальный «джентельменский набор» может состоять из восьми документов:

Основы методологии (Templates, Business Principles, Goals, Drivers). Необходим для понимания миссию, цели, стратегию компании. Зафиксировать бизнес принципы. Шаблон «TOGAF 9 Templates, Business Principles, Goals, Drivers.doc»

Архитектурные принципы (Architecture Principles) – это правила, которыми руководствуются в работе над архитектурой. На их основе принимают архитектурные решения. Принципы нужно сформулировать на основе примеров из TOGAF. Использование принципов при работе над архитектурой доказало свою эффективность. Шаблон – «TOGAF 9 Template Architecture Principles.doc»

Видение архитектуры (Architecture Vision) – это высокоуровневое описание желательного конечного продукта архитектурного проекта. То есть это те результаты, которых нужно достичь. Описание решения тех проблем и задач, ради которых стартуют проект. Этот документ важен для взаимодействия со спонсором проекта и другими заинтересованными лицами. Шаблон – «TOGAF 9 Template Architecture Vision.doc»

Устав проекта (Statement of Architecture Work) – соглашение между спонсором и проектной командой о выполнении работ. В него включают все рамки, ограничения, предположения, сроки, бюджет, правила проекта. В нем конкретно назначают менеджера проекта и прописывают его права и обязанности. Сюда же включают как приложение видение архитектуры как описание рамок проекта. Шаблон – «TOGAF 9 Template Statement of Architecture Work.doc»

Описание архитектуры (Architecture Definition) – это представление текущей и целевой архитектуры. Он охватывает каждый из архитектурных доменов (бизнес, данные, приложения, технологии). А также анализ расхождений между текущим и будущим состоянием. Шаблон – «TOGAF 9 Template Architecture Definition.doc»

Спецификация требований к архитектуре (Architecture Requirements Specification) – документ, в котором собраны все требования, ограничения, предположения, критерии достижения. Шаблон – «TOGAF 9 Template Architecture Requirements Specification.doc»

Переходная архитектура (Transition Architecture) – Реализация целевой архитектуры проходит в несколько этапов. Каждое промежуточное состояние должно быть работоспособно и давать компании большую ценность. В этом документе сгруппированы проекты по каждому из таких этапов. Шаблон – «TOGAF 9 Template Transition Architecture.doc»

План реализации и миграции (Implementation and Migration Plan) – это сводный план реализации проектов, направленных на достижение целевой архитектуры. В него также включают выгоды, рамки, сроки, стоимость, риски, контрольные точки проектов. Шаблон – «TOGAF 9 Template Implementation and Migration Plan.doc»

Такой набор документов можно сделать максимально быстро и без больших затрат. Если предполагается воспользоваться услугами третьих сторон, то рекомендую включить ещё один документ – архитектурный контракт. Это соглашение между архитекторами и исполнителями ИТ проекта. Шаблон – «TOGAF 9 Template – Architecture Contract.doc» При приемке проекта вам будет легче получить нужный результат, если вы о нем заранее договорились.

Подходы к построению ИТ Стратегии

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

Первый шаг – оцениваем текущее состояние Архитектуры Предприятия (Baseline Architecture). Концентрируем внимание на вопросах бизнеса (Business Architecture) и начинаем с общих высокоуровневых вопросов. На данном этапе желательно провести интервью или просто побеседовать с руководством компании, топ менеджерами. Для данной задачи хорошо бы было участие двух специалистов уровня экспертов. Причем один в области управления, консалтинга или аудита, с хорошими аналитическими способностями и пониманием бизнес составляющей (ИТ Директор, Chief Information Officer CIO), а второй, эксперт в области информационных технологий (ИТ Архитектор, Chief Technology Officer CTO). Их главная задача – слушать. Ключевые вопросы, которые помогут удерживать направление беседы в бизнес сфере, сводятся к определению следующих составляющих:

•Основной вид деятельности организации

•Организационная структура

•Особенности ведения бизнеса

•Миссия и видения организации

•Цели и задачи

•Текущие проблемы организации

•Организация и оценка текущего состояние ИТ по мнению руководства

Следующий шаг – формируем видение Целевой Архитектуры Предприятия (Target Architecture). Для этого, задавая наводящие вопросы, пытаемся определить видение руководства, цели бизнеса, ожидания и чаяния. Видение будущего ИТ, его роли, вовлеченность в бизнес и т п. Важный момент данного этапа общения – Не прерывайте их!!! Дайте им высказаться, помечтать. Даже если их фантазии будут время от времени противоречить друг другу, и здравому смыслу. Ваша задача – собрать как можно больше информации. Руководство организации является заказчиком. А как говорится: «… кто музыку заказывает, тот ее и танцует…». Запомните, а затем запишите и проанализируйте всю информацию.

По окончанию первых двух шагов, у нас будет воздушный замок высокоуровневой «Архитектуры Бизнеса» для «Текущей» и «Целевой» Архитектуры Предприятия конкретной организации:

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

Текущая Архитектура

•Архитектура Бизнеса

•Архитектура сегментов

•Информационные Системы

•Техническая Архитектура

План Перехода

•Наброски и идеи

Целевая Архитектура

•Архитектура Бизнеса

•Архитектура сегментов

•Информационные Системы

•Техническая Архитектура

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

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

•корпоративная стратегия (на уровне корпорации, холдинга),

•бизнес-стратегия (на уровне отдельной бизнес-единицы)

•функциональные стратегии (на уровне отдельных функциональных направлений в бизнес-единице).

Диаграмма: Модель дерева проблем – решений» – Проблемы

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

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

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

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

Можно предложить следующие информационные разделы для ИТ-стратегии:

•Цели для ИТ в привязке к бизнес-целям организации.

•Направления развития ИТ для достижения обозначенных целей.

•Проекты, которые должны быть реализованы в рамках каждого направления.

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

•Основные этапы по каждому проекту (краткое описание результатов, сроки, стоимость).

•Набор KPI для мониторинга развития ИТ и достижения соответствующих целей.

•Бюджеты ИТ-проектов, направлений и общий бюджет ИТ.

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

Построении ИТ Архитектуры и ИТ Стратегии в организации можно графически представить в виде диаграммы.

Диаграмма: Модель дерева «проблем – решений» – Решение

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

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

Для чего необходим департамент ИТ (миссия департамента). Миссия ИТ должна отвечать следующим параметрам:

•Соответствие миссии организации

•Соответствовать внутренним и внешним бизнес требованием организации

•Будет ли актуальна в долгосрочной перспективе

•Стратегия централизации информационных систем (одна для всех задач, различные для разных задач)

•Стратегия централизации данных (функциональный, процессный или приложения)

•Стратегия централизации технологической архитектуры (платформа, резервирование и т п)

Что хотим достигнуть (цели). Основные требования к целям компании:

•Отражать специфику работы ИТ департамента

•Реалистичными

•Измеряемы

Какие пути выбрать для достижения цели (стратегия). Под стратегией можно предполагать «выбор путей для создания конкурентного преимущества и достижения определённых показателей организации на рынке». Можно рассматривать два основных направления ИТ стратегии или их комбинацию:

•Наращивание производства или продаж за счет инноваций в области ИТ

•Сокращение издержек за счет оптимизации и реинжиниринга с привлечением ИТ

Каким образом реализовать (проекты). Для эффективной реализации проектов, необходимо, чтобы соблюдались минимальные требования:

•Список проектов (операционный план) должен быть утвержден на уровне совета директоров организации

•Выделен необходимый бюджет, ресурсы и возможности

•Для каждого проекта рассчитаны преимущества (финансовые показатели, ROI, выгоды, риски и т п)

•Проводится мониторинг состояния операционного плана (проектов)

Каким образом измерять (ключевые показатели).

Кто реализует (сотрудники или аутсорсинг)

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

Стратегия финансового контроля

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

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

Ориентироваться на использование свободно распространяемого программного обеспечения

Выравнивание по стоимости или функционалу. Например, стоимость аренды каналов связи для разных филиалов банка может отличаться в зависимости от расстояния или географического расположения. Предположим, что стоимость 10 Mbps канала (стандартные и достаточные ИТ требования) для регионального филиала обходится 500 долларов. За туже стоимость городской филиал может получить скорость канала до 100 Mbps. На текущий момент у этого филиала стандартная скорость 10 Mbps, но обходится за 100 долларов в месяц. Средняя стоимость канала связи для всех филиалов порядка 250 долларов. Руководство должно иметь определённую стратегию по данному вопросу: предоставить возможность филиалам наращивать скорость в пределах средней стоимости, максимальной стоимости или выравнивание всех по установленной скорости канала (10 Mbps).

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

Стратегия административных регуляторов

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

Диаграмма: Уровни управления, задачи и детализации

Стратегия выбора платформа решения

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

«On-premises» – ИТ активы физически располагаются на территории организации.

Преимущества:

•ИТ инфраструктура располагается на территории организации и контролируются ИТ сотрудниками организации.

•Относительно низкой стоимостью сопровождения (OPEX) ИТ инфраструктуры.

•Автономность решений и более высокий уровень безопасности

Недостатки:

•Относительно высокие первоначальные вложения (CAPEX) в ИТ инфраструктуру.

•Внедрение новых сервисов, или резкие скачки (роста) имеющихся сервисов трудно поддается планированию.

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

•Косвенные расходы на инженерные системы ИТ инфраструктуры.

«Cloud based» – ИТ активы располагаются в «облаке».

Преимущества:

•Относительно низкие первоначальные вложения (CAPEX) в ИТ инфраструктуру.

•Высокий уровень планирования расходов на сопровождение ИТ инфраструктуры.

•Хорошая связь, линейная зависимость используемых ресурсов и их стоимости.

•Простота внедрения новых решений и расширения имеющихся ИТ сервисов.

•Нет необходимости в дополнительных сотрудниках.

•Нет необходимости в косвенных расходах на системы инженерные.

Недостатки:

•Относительно высокая стоимость сопровождения (OPEX) ИТ инфраструктуры.

•Более высокие требования к каналам связи интернета и наличию резервных каналов.

«Hybrid» – комбинированное решения. Используются преимущества двух первых решений.

Преймущества:

•Использует достоинства обоих решений.

Недостатки:

•Более высокая стоимость внедрения (CAPEX) и сопровождения (OPEX)

Рекомендации по выбору:

Для начальных проектов, небольших организаций, организаций с развитой географией и т п предпочтительно использование «Cloud based» решения. Для крепкой организации, финансовых институтов, организаций где выход в интернет не является требованием бизнеса и т п предпочтительно использование «On-premises» решения. «Hybrid» решения могут как дополнять ИТ инфраструктуру, так и заменять часть компонентов ИТ архитектуры.

Стратегия выбора платформа развертывания

В качестве платформы для развертывания инфраструктуры, при условии, что выбрано «On-premises» решение, могут быть рассмотрены следующие варианты:

«Физические сервера» – ИТ сервисы располагаются на физических серверах.

Преимущества:

•Относительно низкой стоимостью внедрения (CAPEX) ИТ сервисов для малых решений.

•Ресурсы физического сервера полностью выделены по задачи конкретного сервиса.

Недостатки:

•Сложность сопровождения, с ростом инфраструктуры.

•Скорость развёртывания и восстановления.

•Не оптимальное использование вычислительных ресурсов.

«Платформа виртуализации» – ИТ сервисы располагаются на платформе виртуализации в виде виртуальных машин.

Преимущества:

•Относительно низкая стоимость сопровождения (OPEX) в ИТ инфраструктуру.

•Фактически является «де-факто» стандартов развертывания «On-premises» решений.

Недостатки:

•Относительно высокая стоимость внедрения (CAPEX) ИТ инфраструктуры.

Рекомендации по выбору:

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

Стратегия выбора аппаратного и программного обеспечения

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

Использование определённого производителя для каждой категории ИТ активов. Использование стандартов аппаратного и программного обеспечения в организации.

Преимущества:

•Внедрение стандартов ИТ активов упрощает процесс обеспечения сотрудников организации ИТ активами.

•Облегчает внедрение и сопровождение ИТ инфраструктуры

•Повышает уровень информационной безопасности организации.

Недостатки:

•Относительно высокая стоимость и зависимость от производителя и/или поставщика.

Использование произвольного производителя. Использование рекомендаций вместо стандартов для аппаратного и программного обеспечения в организации.

Преимущества:

•Относительно низкая стоимость и быстрота приобретения ИТ активов.

Недостатки:

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

•Усложняет внедрение и сопровождение ИТ инфраструктуры

•Снижает уровень информационной безопасности организации.

Рекомендации по выбору:

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

Стратегия лицензирования

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

Использование лицензионного соглашения уровня «Предприятия» с ежегодным продлением возможности обновления программного обеспечения. Лицензирование является непрерывным процессом в ИТ.

Преимущества:

•Большая степень свободы в вопросах лицензирования.

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

•Обновление систем происходит плавно, без всплесков требований в ИТ ресурсах, людях и времени

Недостатки:

•Относительно высокая стоимость.

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

Преимущества:

•Относительно дешевле по стоимости

Недостатки:

•Меньшая степень свободы в вопросах лицензирования.

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

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

Рекомендации по выбору:

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

Стратегия построения инженерных систем

Для «On premise» и «Hybrid» решений требуется определится с требованиями к инженерным системам.

К требованиям по инженерным системам можно отнести:

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

•Требования к Структурированной Кабельной Системе (избыточность, резервирование и т п)

Стратегия тестирования

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

•«Test или Development» – площадка с развернутыми отдельными ИТ сервисами. Используется для разработки сервисов или отладка элементов ИТ сервиса.

•«Pre-production» – уменьшенная копия «Production» площадки со всеми компонентами ИТ архитектуры. Используется для отработки взаимодействия ИТ сервисов между собой. Так же позволяет эмулировать ситуации при поиске неисправностей, расчет производительности и т п.

•«Production» – площадка с развернутым вычислительными ресурсами предоставляющие ИТ сервисы.

Рекомендации по выбору:

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

Стратегия уровня избыточности

Определение уровня избыточности компонентов ИТ инфраструктуры указывает требования к дублированию компонентов. Может рассматриваться на уровне:

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

•Каналы и кабели связи (два и более проходящие по разным шахтам),

•Избыточное количество рабочих точек (обеспечивает рост организации и резерв на отказ)

Компонентов устройства (сервера, коммутатора и т п). Резервирование (дублирование) на уровне критически важных элементов устройства, таких как:

•Процессоры (два и более процессоров),

•память (две и более «банки» памяти),

•жесткие диски (два диска в RAID1 массиве + один резервный)

•сетевые карты и адаптеры (две карты с одним и более портами)

•блоки питания (N+N или N+1)

Компонентов ИТ сервиса. Резервирование на уровне устройств и типу их включения. Как пример:

•Два сервера в отказоустойчивом кластере

•Два сервера выполняющих одну и туже роль (два контролера домена)

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

Географически разнесенные устройства в пределах сайта. Расположение пары устройств в разных стойках, помещениях или зданиях в пределах одного сайта.

Географически разнесенные устройства на уровне сайтов. Расположение пары устройств на разных сайтах.

Определение уровня резервирования зависит от критичности бизнеса к отказу или простою. Анализируется в процессе Управления Рисками, формализуется в документах по стандартах оборудования.

Стратегия по системам резервирования и архивирования

К системам резервирования и архивирования ИТ инфраструктуры можно определить следующие требования:

•Компоненты систем должны быть установлены на выделенных физических элементах (серверах, СХД и т п)

•Возможно совмещение систем резервирования и архивирования на одних компонентах.

•Права доступов для учетных записей (автоматического) резервного копирования по возможности не должны предоставлять возможность удаления данных или же их перезапись.

Требования к резервным сайтам

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

•Отказоустойчивость на уровне отдельных компонентов ИТ сервиса

•Отказоустойчивость на уровне дублирования компонентов ИТ сервиса

•Отказоустойчивость в пределах сайта

•Отказоустойчивость с географически распределённым сайтом

Различают следующие категории специализированных резервных площадок:

•«Горячий» – готовность в течении секунд/минут/часов

•«Теплый» – готовность в течении часов/дней (порядка 48 часов)

•«Холодный» – готовность в течении дней/не полное восстановление

Не специализированные площадки – использование имеющуюся площади организации (филиал и т п)