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

27.03.25

Архитектура - Архитектура данных

При проектировании информационной системы архитектору важно думать не только о ее запуске, но и о долгосрочной работе – на 5-10 лет вперед. Он должен заглянуть в будущее, предвидеть возможные вызовы при эксплуатации и развитии, и учесть эти факторы. По сути, архитектору для выполнения своей работы нужно уметь путешествовать во времени. Расскажем о выстраивании управления архитектурой информационных систем, которое помогает организации достигать своих стратегических целей, минимизируя риски и оптимизируя ресурсы.

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

Расскажу:

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

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

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

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

 

 

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

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

  • Численность сотрудников – более 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С. Для глубокой разработки мы нанимаем подрядчиков, и они делают проекты со своими экспертами. Мы только координируем, чтобы это все в нашу экосистему вписалось, с разными другими системами корректно работало.

 

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

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

См. также

Анализ потребностей и поиск решений Архитектура решений Бесплатно (free)

В четырнадцатом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, что из себя представляют облачные технологии и какие возможности они предоставляют для работы с решениями 1С.

11.03.2025    340    0    Radio_Analyst    0    

5

Архитектура решений Платформа 1С v8.3 1C:ERP 1С:КА Управленческий учет Бесплатно (free)

Давайте решим задачку, как скрестить на проекте внедрения ERP в одном отчете данные нескольких ключевых отчетов: по финансовым результатам, по взаиморасчетам, по структуре себестоимости и ОСВ. И затратить на разработку не более 20 часов, переложив всю работу на аналитиков. Использовать будем функциональность подсистемы бюджетирования в ERP. Поскольку задача - архитектурно-управленческая - статья про ход мысли. Так что слов будет много, картинок не очень, а техническое решение - в конце статьи.

06.03.2025    440    0    ovetgana    2    

3

Архитектура данных Анализ предметной области Бесплатно (free)

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

26.02.2025    506    0    MarryP    0    

2

Архитектура решений Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

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

27.01.2025    1927    0    jf2000    3    

4

Проектирование Архитектура данных Бесплатно (free)

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

17.12.2024    410    0    Radio_Analyst    0    

3

Архитектура решений Бесплатно (free)

«1С:Розница» и «1С:Управление нашей фирмой» (1С:УНФ) вместе с программой «1С:Рабочее место кассира» (1С:РМК) представляют линейку решений для малого бизнеса. Решения линейки имеют единую архитектуру, код и пользовательские интерфейсы, что обеспечивает простое совместное использование и легкий переход между решениями по мере развития бизнеса. Разработка программ линейки решений ведется одной командой, в одном репозитории, полностью на общем коде. Расскажем о специфике такой разработки и преимуществах унификации решений 1С.

05.12.2024    688    0    Samigullina_KI    3    

4

Архитектура решений Платформа 1С v8.3 Управленческий учет Бесплатно (free)

На связи Анна Астахова, коммерческий директор ИТ-интегратора «Белый код». У компаний за последние 3 года появилось больше каналов коммуникации с клиентами. Сегодня у многих есть сайт, канал в Telegram, группа в «ВКонтакте» и так далее. Здесь скидка, тут баллы — как этим управлять легко с помощью 1С?

21.10.2024    572    0    user1980363    0    

1

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

14.10.2024    5027    0    comol    29    

30
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. user-z99999 78 27.03.25 13:55 Сейчас в теме
Меня зовут Павел Мутовин, я архитектор информационных систем «Иркутской нефтяной компании».

А где можно ознакомиться с перечнем технологий, с которыми вы знакомы? (и кроме названий, насколько глубоко)

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