Портал №1 по управлению цифровыми
и информационными технологиями

Детализация прикладного слоя в управлении конфигурациями

Компании, которые выстраивают свой конфигурационный учет впервые всегда сталкиваются с вопросом: «Как нам учитывать приложения при построении моделей конфигурации наших ИТ-услуг».

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

Схема, изображенная на рисунке выше, хороша только для того, чтобы показать неискушенному менеджменту укрупненную схему «ERP, и как мы ее используем». Для решения задач, стоящих перед ИТ-департаментом, таких как расчет и обоснование стоимости ИТ-услуг, например, или оценка влияния инцидентов и изменений, эта схема уже не подходит. Давайте посмотрим почему.

Разделяй и властвуй

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

Разработчики приложений давно осознают эту потребность, поэтому монолитные приложения практически канули в лету и архитектурно распались на некоторый набор подсистем. Если приложение не построено полностью на микросервисах, то, исторически, эти подсистемы подразделяются на базовые и на профильные. Базовые обеспечивают некоторую общую функциональность, например MDM, механизмы ведения ролевой модели доступа к данным, хранение свойств пользовательской сессии, интеграцию с СУБД. Профильные обеспечивают функциональные возможности для непосредственной работы пользователей в тех или иных профессиональных областях.

Такое увеличение детализации может позволить чуть более определенно ответить на вопрос какие укрупненные блоки системы используются для тех или иных бизнес процессов.

Очевидно, что в реальной жизни ни в одной подобной сложной системе профильные подсистемы никогда не работают обособленно. Мы будем предполагать наличие некоторого API, позволяющего обмениваться данными между подсистемами. Функции которые реализуют публичные методы этого API являются частью своих предметных подсистем, даже если транспорт этого API является общесистемным. Поэтому будем считать, что API является неотъемлемым компонентом подсистем.

Молекулярный слой

Следующий очевидный факт, который не обозначен на схеме выше, — это взаимозависимость подсистем. Стрелки должны были обозначать зависимость (и потребление ресурсов) одних элементов схемы другими. Мы не отказывались от этой семантики, но на этой схеме сейчас нельзя отобразить качество и природу зависимости одной подсистемы от другой, это вынуждает нас дробить подсистемы на детальные компоненты.

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

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

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

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

Если же компания пользуется приобретенным ПО как «черным ящиком» и не управляет его разработкой, то необходимость в дроблении такого ПО на компоненты отсутствует. Действует принцип разумной достаточности, в рамках которого в конфигурационном учете выделяют только те элементы, которыми компания в силах управлять: например, отдельные интеграционные интерфейсы с коробочным ПО. Эти интерфейсы могут быть отражены как часть этого ПО или в форме самостоятельных приложений, в зависимости от их природы.

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

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

Атомный вывод

Если компания хочет успешно управлять рисками, связанными с теми или иными приложениями, то ей не стоит отходить от принципа «Сделал — записал»!

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT