Меня зовут Павел Мутовин, я архитектор информационных систем «Иркутской нефтяной компании». Хочу поделиться с вами опытом нашей компании по выстраиванию процесса управления архитектурой информационных систем.
Расскажу:
-
Как мы вообще пришли к необходимости управлять архитектурой и решили выделить отдельную роль – архитектор информационных систем.
-
Какие функции выполняет архитектор.
-
Какую методологию и какие инструменты мы используем для управления архитектурой.
-
И как у нас целом устроен этот процесс.
Немного о компании:
-
Иркутская нефтяная компания – крупнейшая частная нефтегазодобывающая компания в России.
-
Численность сотрудников – более 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С. Для глубокой разработки мы нанимаем подрядчиков, и они делают проекты со своими экспертами. Мы только координируем, чтобы это все в нашу экосистему вписалось, с разными другими системами корректно работало.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
