Построение и развитие ИТ-архитектуры организации

ИТ-архитектура является одним из важнейших компонентов организации (корпоративной архитектуры). Есть различные стандарты, подходы и модели (framework) к построению и развитию ИТ-архитектуры и корпоративной архитектуры, например: ITIL, TOGAF, ISO 15288, 20000, 27000, Zachman, COBIT, IT4IT и др. В данной статье рассмотрим комплекс основных этапов, который уже многократно зарекомендовал себя и апробирован во многих организациях. Каждый этап состоит из набора взаимосвязанных задач и инструкций. Детально они рассмотрены в источниках [1], [2] и [3].

Для создания всех графических моделей, реестров и справочников (классификаторов) по ИТ-архитектуре рекомендуется использовать специализированные программные продукты, например Business Studio, Archi, Microsoft Visio + Excel. Ключевыми исполнителями данных работ являются: ИТ-архитектор и ИТ-департамент в целом, процессный офис (или департамент бизнес-архитектуры), рабочие группы (команды) по соответствующим направлениям.

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

12 этапов построения и развития ИТ-архитектуры организации

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

1. Разработка ИТ-стратегии

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

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

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

2. Разработка иерархического реестра (каталога) всех ИТ-систем и ИТ-платформ организации

В точки зрения TOGAF должно быть построено два иерархических реестра (дерева): слой приложений (application layer), слой системных технологий и ИТ-платформ (technology layer).

Первый слой (реестр) необходимо детализировать до модулей и функций (см. Рис. 1). В зависимости от размера организации данный реестр может иметь 5-8 и более уровней детализации (иерархии).

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

• CRM и Front-office (маркетинг, продажи, работа с клиентами)

• Электронный документооборот (ЭДО)

• Кадровые и зарплатные системы

• Бухгалтерские системы

• Офисные системы (работа с документами и таблицами)

• BPMS (управление процессами и задачами)

• Юридические системы (договора, законодательство)

• Системы информационной безопасности (Firewall, Antivirus)

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

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

3. Заполнение детальных параметров (карточек, спецификаций) всех ИТ-систем и модулей

 Карточка ИТ-системы (см. Рис. 1) должна давать наиболее полную, структурированную и актуальную информацию, которая включает следующее:

• Контуры функционирования: test (development), pre-production, production.

• Площадки и расположение: «облачное, cloud based» (за пределами организации), собственные ресурсы.

• Типы лицензий: временные (подписка), постоянные.

• Оборудование и ИТ-платформы, на которых работают ИТ-системы (приложения).

• Владелец ИТ-системы в организации (ответственный).

• Сроки (периодичность) обновления, сроки оплаченной внешней техподдержки.

• Версия и тип (категория) ИТ-системы.

• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX).

• Операционные риски и риски информационной безопасности.

• Влияние на критичную архитектуру организации.

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

• Срок восстановления системы в случае сбоев.

• Максимальное количество пользователей.

• Зависимость от иностранного программного обеспечения.

• Комментарии и техническая информация.

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

4. Разработка архитектурных моделей ИТ-систем

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

5. Разработка графических моделей по интеграции (связям) ИТ-систем

Необходимо отобразить ключевые потоки данных (см. Рис. 3) между ИТ-системами организации (ИС1 <=> ИС2), между ИТ-системами и базами данных (ИС1 <=> БД1), между ИТ-системами организации и внешними субъектами, другие виды связей (в зависимости от специфики организации). Дополнительно может быть указана информация о протоколах, шлюзах, сервисах, требованиях и т.п.

6. Разработка иерархического реестра (каталога) всех баз данных (структур данных) и их параметров

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

7. Разработка технической архитектуры и дополнительных моделей (в зависимости от задач)

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

Для объектов архитектуры оборудования могут задаваться следующие параметры:

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

• Зависимость от иностранных производителей.

• Сроки периодического технического обслуживания и ремонта.

• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX).

• Влияние на критичную архитектуру организации.

• Расположение оборудования (локация).

• Операционные риски и риски информационной безопасности по оборудованию.

• Требования к отказоустойчивости, дублированию, резервированию.

• Комментарии и другая информация.

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

В дополнение к технической архитектуре могут разрабатываться другие модели под разные задачи, например в форматах (нотациях): BPMN, ArchiMate, UML. Большое количество примеров содержатся в источниках [1] и [3].

8. Установление связей объектов и моделей ИТ-архитектуры с объектами и моделями бизнес-архитектуры

Очень важно, чтобы построение и развитие ИТ-архитектуры и бизнес-архитектуры выполнялось внутри одной базы данных и платформы, например Business Studio [4]. Только в таком случае мы сможем быстро и эффективно установить большое количество связей (со стратегией, бизнес-процессами, показателями KPI, организационной структурой), проследить взаимные влияния, оценить функционирование и полноту (целостность) всей корпоративной архитектуры.

9. Проработка операционных рисков (ИТ-рисков) и системы информационной безопасности

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

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

10. Разработка нормативных документов и форм документов

Все рассмотренные выше этапы (работы) и их результаты должны быть детально документированы, см. [1]. Разрабатываются и актуализируются нормативные документы, например:

• Положение об ИТ-архитектуре

• Положение об интеграции ИТ-систем

• Порядок ввода (передачи) программного обеспечения в эксплуатацию и вывода из эксплуатации

• Порядок установки, модификации и обслуживания объектов ИТ-инфраструктуры

• Регламент доработки, тестирования и внесения изменений в ИТ-системы

• Положение о распределении прав доступа к ИТ-системам

• Положение об информационной безопасности

• Многое другое

Под формами документов подразумеваются различные образцы и шаблоны: технические задания, заявки, планы, отчёты, приказы, договора, SLA-соглашения и др.

11. Проведение аудита (оценки) ИТ-архитектуры по чек-листу и аналитических работ

Необходимо разработать и заполнить чек-лист с детальными требованиями (более 100). Фрагмент приведён на Рис. 4. Способы оценки требований: наблюдение за работой ИТ-систем и оборудования, наблюдение за работой ИТ-персонала, интервью и опросы сотрудников, изучение документов и отчётов (включая историю значений показателей, историю операционных рисков и др.). На основе проведённого аудита составляется план задач для проработки выявленных недостатков и включается в план развития (оптимизации) ИТ-архитектуры на следующий период (этап 1).

12. Сбор новых требований и задач к автоматизации и цифровизации от подразделений

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

Рис. 1. ИТ-архитектура (на примере банка, фрагмент) и карточка (набор параметров) ИТ-системы

   Рис. 2. Архитектурная модель программного продукта (на примере Business Studio)

Рис. 3. Модели интеграции ИТ-систем (общий вид, без детализации названий фигур и стрелок)

Рис. 4. Фрагмент чек-листа «Диагностика и аудит ИТ-архитектуры организации»

Рекомендуемая литература и источники информации:

[1] Большая библиотека системного аналитика и ИТ-архитектора.

[2] Исаев Р.А. ИТ-архитектура организации и система регламентации ИТ-департамента.

[3]  Исаев Р.А. 60 примеров успешных и проблемных проектов организационного развития.

[4] IT Architect: система управления ИТ‑архитектурой.

[5] Большая библиотека риск-менеджера и специалиста по операционным рискам