Назад в будущее. Как мы выстраиваем процесс управления архитектурой информационных систем

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

Расскажу:

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

• Какие функции выполняет архитектор.

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

• И как у нас целом устроен этот процесс.

Немного о компании:

• Иркутская нефтяная компания – крупнейшая частная нефтегазодобывающая компания в России.

• Численность сотрудников – более 14 000 человек. Компания активно растет – в ближайшее время планируется открытие шести новых заводов и прирост численности на 1500 сотрудников

• Блок информационных технологий в компании насчитывает 250 человек.

• Из них Департамент информационных систем – около 110 человек.

• В компании используется более 200 информационных систем и сервисов, из них 60% – на 1С.

• Каждый год мы реализуем около 100 ИТ-проектов – это в основном модернизация, но объем работ очень большой.

Практика управления архитектурой. Как мы к этому пришли

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

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

• При этом отсутствовала единая карта обмена данными между информационными системами.

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

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

• Важно было исключить дублирование функций.

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

При проектировании архитектуры информационных систем мы учитывали следующие аспекты:

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

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

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

• Количество и объем обрабатываемой информации с учетом ежегодного прироста.

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

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

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

Функции архитектора информационных систем

На архитектора информационных систем были возложены следующие функции:

• Разработка методологии по управлению архитектурой.

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

• Внедрение методологии, чтобы она стала неотъемлемой частью сервисной модели, по которой мы работаем.

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

• Моделирование текущей и будущей архитектуры.

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

• Проектирование архитектурных решений.

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

• Архитектурный надзор – поскольку мало спроектировать, нужно еще и реализовать этот проект.

• Оценка принятых архитектурных решений по результатам эксплуатации – один из этапов цикла PDCA. К примеру, через 3?6 месяцев необходимо оценивать работу архитектора и работу практики в целом.

Архитектурное решение – это всегда компромисс между:

• стоимостью;

• сроками;

• эффективностью;

• архитектурным видением;

• текущими наработками;

• ограничениями и допущениями.

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

Подходы к проектированию и построению архитектуры

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

• Видение архитектуры

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

• Архитектура информационных систем

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

• Возможности и решения

• Планирование миграции

• Управление реализацией (AS IS и TO BE)

• Управление изменениями архитектуры.

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

Само понятие архитектуры в фреймворке TOGAF разделяется на три слоя:

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

• Архитектура информационных систем;

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

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

В качестве языка моделирования мы используем Archimate – он полностью соответствует фреймворку TOGAF.

В Archimate слои и элементы архитектурного описания выделяются цветами:

• Желтый цвет – это бизнес-слой;

• Голубой – слой приложений;

• Зелёный – слой технологической архитектуры;

• Фиолетовым цветом выделяются структурные элементы в части стратегии и мотивации;

• Розовым – в части реализации и миграции.

Элементы нотации Archimate разделяются на различные группы.

• По слоям и элементам архитектурного описания – цветовое разделение, о котором я уже упомянул.

• По типам элементов – пассивные, активные и поведенческие элементы.

• По видам элементов – например, артефакт, процесс, шлюз и прочие.

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

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

Можно провести аналогию C4 model с картой мира: сначала мы видим страну, ближе – город, ещё ближе – дома и улицы.

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

Модель C4 получила свое название благодаря четырем уровням, каждый из которых начинается с буквы «C»:

• Context – информационные системы

• Containers – подсистемы, модули. Веб-приложения, мобильные приложения, настольные приложения, база данных, файловая система

• Components – каждый контейнер может состоять из нескольких компонентов

• Code – каждый компонент реализуется одним или несколькими элементами кода (классы, интерфейсы, объекты, функции…)

Моделирование архитектурных схем. Инструменты

В качестве инструмента моделирования мы используем продукт Archi, который полностью соответствует фреймворку TOGAF.

• Самое важное преимущество Archi – он бесплатный и при этом живой, его регулярно актуализируют.

• Archi полностью поддерживает нотацию Archimate.

• Содержит библиотеку элементов, соответствующую структурным элементам Archimate.

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

Каждый отдельный элемент можно рассмотреть:

• его описание, функции, метаданные, которые вы зададите;

• с какими другими структурными элементами он связан и каким образом;

• и какие элементы с ним связаны.

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

Единственный недостаток Archi – это не сетевое приложение, для работы с ним его нужно установить локально.

Чтобы сделать у Archi многопользовательским и использовать его совместно с другими архитекторами, есть бесплатный плагин coArchi. Его можно установить в GitLab – таким образом у Archi появляется возможность работать с Git, т.е. коммитить, зачитывать, осуществлять совместную работу так же, как это делают разработчики с использованием Git.

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

Управлять доступом к GitLab и устанавливать каждому айтишнику Archi нам показалось трудозатратным, поэтому мы воспользовались волшебной функцией – в Archi можно сделать экспорт отчета в виде HTML-страницы.

Папку, где находится это HTML-страница, мы просто замапили на IIS – прописали доступ к этой папке IIS на уровне Active Directory только для нашего Блока. Таким образом у нас получился сайт.

Важно, что в Archi все архитектурные схемы – это отдельные представления с фиксированным ID. Даже если мы обновляем схему, ID не меняется. Нам не нужно обмениваться картинками, достаточно отправить гиперссылку на архитектурную схему. Это очень удобно.

Организация процесса

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

• Разработали регламент «Управление архитектурой» – те правила, по которым мы работаем с архитектурой у нас в компании.

• Разработали стандарт «Моделирование архитектуры», построенный на TOGAF и Archimate – в других компаниях такой стандарт может называться «Соглашение о моделировании». В том числе, мы предлагаем нашим подрядчикам при моделировании архитектуры для нас использовать этот стандарт.

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

• Разработали архитектурное видение.

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

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

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

Хочу завершить доклад цитатой из книги Роберта Мартина «Чистая архитектура. Искусство разработки ПО».

Цель архитектуры программного обеспечения – уменьшить человеческие трудозатраты на создание и сопровождение системы

Надеюсь, опыт нашей практики будет кому-то полезен.

Вопросы и ответы

Кто участвует в описании архитектуры, и кто использует полученные результаты?

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

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

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

Используется ли инструмент ADR и ведется ли реестр ADR?

ADR мы пока что не используем, так как ADR – это в первую очередь про бизнес, а только потом уже про информационные системы.

Какова у вас численность архитектурной службы? Есть ли планы увеличить детализацию по C4, и как это повлияет на численность службы?

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

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

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

• Первый уровень – это информационные системы.

• Второй уровень – это компоненты, подсистемы, модули.

• Третий уровень – артефакты, но он у нас был задействован только в одном проекте.

• А четвертый уровень мы не используем, потому что в основном занимаемся разработкой только на 1С, и архитектурные схемы для разработчиков еще не рисуем – у нас пока нет в этом постоянной потребности.

Привлекаете ли вы сторонних архитекторов? Какое максимальное количество привлеченных архитекторов у вас было? Не рассеивается ли при этом фокус внимания?

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

Различается ли соглашение о моделировании для внешних и для внутренних подрядчиков?

Соглашение о моделировании для всех одно. Все, кто хочет с нами работать, должны работать по нашим правилам.

Вы говорили, что у вас в год запускается по сто проектов. Как это организовано? Как архитектор вовлекается в проекты?

Сто проектов в год – это не глобальные проекты вроде внедрения ERP, а, в основном, модернизация.

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

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

Если изменения касаются обмена данными или компонентного состава, согласование обязательно.

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

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

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

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

Особенность нашей компании в том, что мы глубокой разработкой не занимаемся – мы только дорабатываем 1С. Для глубокой разработки мы нанимаем подрядчиков, и они делают проекты со своими экспертами. Мы только координируем, чтобы это все в нашу экосистему вписалось, с разными другими системами корректно работало.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.