
Полная версия:
ИТ-архитектура. Практическое руководство от А до Я. Первое издание
Теперь повторяем те же шаги, но общаясь с руководством среднего звена, экспертами и ИТ компании. На данном этапе можно и нужно углубиться в детали, активно задавать вопросы, понять проблемы, рекомендации и опыт сотрудников. Как правило, можно подчерпнуть ценную информацию, понять ограничения и причины проблем, совместно набросать планы решения проблем. В результате получаем практически полную картинку:
Текущая Архитектура
•Архитектура Бизнеса
•Архитектура сегментов
•Информационные Системы
•Техническая Архитектура
План Перехода
•Наброски и идеи
Целевая Архитектура
•Архитектура Бизнеса
•Архитектура сегментов
•Информационные Системы
•Техническая Архитектура
Процесс итерации можно повторять бесконечное число раз пока не добьетесь 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 часов)
•«Холодный» – готовность в течении дней/не полное восстановление
Не специализированные площадки – использование имеющуюся площади организации (филиал и т п)
Подходы по внедрению Архитектуры Предприятия
При разработке архитектуры вашей компании необязательно начинать с разработки стратегической архитектуры. Безусловно, подход «Сверху – Вниз» (Стратегическая архитектура – > Архитектура сегмента – > Архитектура решений) самый распространенный и имеет множество преимуществ:
•Будет понятен общий вектор развития организации.
•На уровне сегментов и решений будет меньше разброда и шатаний.
•Общие правила и подходы на уровне организации, а затем их трансляция на уровень сегментов и решений.
•Общие для компании информационные системы и сервисы, повторно используемые на уровне сегментов и решений.
Основная идея движение от «общего к конкретному» (Generic- to – specific), а также непрерывное совершенствование ИТ архитектуры на основе требований бизнеса. Но вы можете использовать и другие подходы:
«Снизу – Вверх» (Архитектура решений – > Архитектура сегмента – > Стратегическая архитектура). От архитектуры конкретных проектных решений к стратегической архитектуре. Компания начинает с архитектуры решения. До старта проекта решение прорабатывается и описывается. Затем – более высокие уровни Архитектуры Предприятия. Этот метод позволяет быстро получить ценность от методов Архитектуры Предприятия. Но есть вероятность, что без стратегической архитектуры, как основы, архитектуры различных решений «разъедутся». Придется потратить время и ресурсы на приведение их к общему знаменателю.
«От Сегмента» (Архитектура Сегмента – > Архитектура решений и стратегическая архитектура) Когда компании важно решить проблемы в конкретном подразделении, запустить новое направление бизнеса, либо если компания не готова к крупномасштабным внедрениям Архитектуры Предприятия и хочет «потренироваться на кошечках». Обкатать идеи на одном подразделении или направлении бизнеса. В зависимости от целей и сроков их достижения вам нужно выбрать подход для вашей компании.
Информационные системы вашей компании возможно далеки от идеала. Но выбросить их и переделать будет стоить очень дорого и займет много времени. Ценность такой инициативы сильно ниже нуля. Опытный архитектор «полечит» проблемы с интеграцией, информационной безопасностью, инфраструктурой, заплатками, а саму систему заставит давать большую ценность вашей компании. Реализация будет идти небольшими, точно выверенными доработками. Он будет решать конкретные проблемы, а не «делать все по уму». Замена системы – это серьезное изменение для компании, и для него должны быть веские аргументы.
Следующий важный вопрос при внедрении проекта построения Архитектуры Предприятия: Стоит ли привлекать консультантов или делать все самим (MAKE or BUY)? Однозначного ответа на него нет. Все зависит от конкретной организации, целей и возможностей. Для примера, представим ситуацию:
Мы заключаем контракт с уважаемой компанией «СУПЕР ПУПЕР КОНСУЛЬТАНТЫ и Ко». Через несколько месяцев получаем набор документов под названием «Архитектура компании БАНАНАС и Ко», в котором расписана правильная система, множество схем, описаний и т п. Так сказать решение «под ключ». Заманчиво? Да скорее всего дорого, но быстро, профессионально, не один «комар» (читаем «аудитор») носу не подточит. Возможно.