Управление приложениями: кто отвечает за приложение и что с ним будет дальше

Что это значит на практике

Приложение — это программа, в которой работают люди: учётная система, склад, кадры, интернет-магазин. С такой программой связаны три разные работы, и их постоянно путают. Разработка создаёт приложение и заканчивается выпуском. Эксплуатация держит его в рабочем состоянии сегодня: чтобы оно запускалось, не тормозило и было доступно людям. Управление приложениями отвечает на третий вопрос, самый неудобный: что с этой программой будет через три-пять лет — развивать, переписывать, заменять или выводить из эксплуатации. Такой горизонт задаёт стратегический уровень ASL — свода знаний, целиком посвящённого управлению приложениями. Пока на этот вопрос никто не отвечает, приложение живёт по инерции — до дня, когда поддерживать его окажется некому и нечем.

Если вы искали управление приложениями на телефонах и ноутбуках сотрудников

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

Значение первое, техническое. Установить приложения на рабочие телефоны и ноутбуки сотрудников, обновить их разом, запретить установку лишних, стереть данные с потерянного устройства. Такие системы называют средствами управления мобильными устройствами, и по запросу «управление приложениями» поисковые системы показывают в основном их.

Значение второе, управленческое — и эта страница про него. Приложение здесь не значок на экране телефона, а система, на которой держится работа целого подразделения или всей компании: бухгалтерия, склад, кадры, продажи. У такой системы есть владелец и стоимость владения. Вечной она не будет, и кто-то должен решать её судьбу.

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

→ Управление лицензиями и ПО. Какое ПО стоит на устройствах компании и на каких условиях она им владеет: лицензии, подписки, права.

Кто такой владелец приложения

Слово «владелец» сбивает чаще всего. На практике владельцем приложения часто зовут того, кто его чинит: администратора, разработчика, дежурного инженера. Это исполнитель, а не владелец.

Владелец приложения — та сторона, ради которой приложение существует и которая получает от него пользу. Обычно это подразделение бизнеса: бухгалтерия для учётной системы, продажи для системы работы с клиентами, кадры для системы найма. Разбор «ITIL V3 and ASL» называет владельцем информационной системы организацию-пользователя: ту, что получает пользу от возможностей системы и отвечает за информационное обеспечение организации целиком — то есть за то, какими системами она вообще работает. Этот разбор в январе 2008 года выпустили фонд ASL BiSL и TSO, издатель книг ITIL.

Из этого следует правило, которое нарушают постоянно: требования к приложению задаёт владелец, а не программисты. Практическое руководство ITIL 4 по разработке и управлению ПО помещает эту работу между четырьмя сторонами. Владельцы приложения определяют требования к его разработке и к управлению им. Инфраструктурные команды дают среды, в которых приложение собирают и запускают. Пользователям нужна помощь в работе. Подрядчикам часть работы передали, и с ними договариваются отдельно.

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

• владелец решает, зачем приложение нужно и что в нём менять;
• владелец отвечает за деньги — и за развитие, и за поддержку;
• владелец принимает решение о судьбе системы и объявляет его;
• тот, кто чинит и меняет, — это другая роль, исполнительская.

→ Разработка и управление ПО. Что ещё владелец задаёт команде: требования к качеству, сопровождаемости и управляемости приложения.

Чем это отличается от разработки и от эксплуатации

Путаница здесь не от невнимательности: разные своды знаний называют одним словом разные наборы работ. Тот же разбор «ITIL V3 and ASL» называет оба термина омонимами — одним словом с несколькими значениями — и показывает разницу таблицей.

• создать новое приложение: у ITIL это разработка, у ASL тоже разработка;
• дорабатывать уже работающее: у ITIL разработка, у ASL управление приложениями;
• поддерживать работу уже выпущенного приложения: у обоих управление приложениями.

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

Разница между «написать новое» и «дорабатывать существующее» не в объёме кода. Авторы разбора называют три причины, по которым доработка сложнее первичной разработки:

• сроки жёстче: новую версию часто надо выпустить к дате, когда меняется закон или на рынок выходит продукт, который действующая система должна поддержать;
• обратная связь приходит быстрее: небрежная доработка возвращается к автору сразу, и разбираться с ней приходится немедленно;
• свободы меньше: менять приходится внутри решений, которые приняли несколько лет назад, и вместо идеального варианта обычно берут тот, что просто заработает.

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

Что входит в работу: три уровня и шесть групп процессов

ASL 2 выделяет шесть групп процессов и относит их к трём уровням — операционному, управляющему и стратегическому.

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

Обратите внимание, где в этом списке стоит вопрос о далёком будущем: в двух последних группах. Разбор «ITIL V3 and ASL» прямо объясняет, зачем они заведены, — подразделения, которые сопровождают приложения, известны своим консерватизмом, и стратегический уровень нужен, чтобы они думали не только о завтрашних запросах заказчика, но и о собственном завтра. А если ни за одной из этих двух групп в организации никто не закреплён, вопрос «что с системой через три года» обычно так и остаётся незаданным.

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

• исправляющее — чинят ошибки в программе, которые уже привели к сбоям;
• предупреждающее — чинят ошибки до того, как они проявились;
• приспосабливающее — приводят приложение в соответствие с изменившейся средой: новая операционная система, новая версия базы данных;
• улучшающее — расширяют возможности, удобство и быстродействие.

Сколько стоит приложение и почему счёт за лицензии — не ответ

Для большинства цена приложения — это стоимость проекта: сколько заплатили за разработку или за готовый продукт. Практическое руководство ITIL 4 «Software development and management» приводит числа, после которых разговор о цене выглядит иначе.

Приложение живёт от нескольких месяцев до нескольких десятилетий, в среднем десять-пятнадцать лет. Исторически на разработку приходилось около 20 % совокупной стоимости владения приложением, а остальное — на управление им; и около 20 % затрат на управление уходило на исправление дефектов. Иначе говоря, решение написать или купить приложение — это решение о расходах на десять лет вперёд, а не о цене проекта.

Есть и расход, которого в бюджете не видно вовсе. Качество программы ухудшается само, если в неё не вкладываться, — в ITIL 4 это названо энтропией программного обеспечения: чем дольше в программу не вкладывают сил, тем труднее и дороже её менять. Накопленную переделку — ту, что появляется, когда выбирают быстрый обходной путь вместо правильного, но долгого решения, — называют техническим долгом. По тому же руководству на понимание чужого кода уходит около половины усилий сопровождения: чем труднее разобраться в приложении, тем дороже каждое следующее изменение.

Какие расходы обычно не считают, прежде чем назвать приложение дешёвым:

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

→ Управление финансами. Как считают затраты на ИТ в разрезе услуг, чтобы стоимость была известна, а не оценивалась на глаз.

Как понять, что приложение пора выводить

Признаков того, что приложение пора выводить из эксплуатации, немного, и все они видны заранее:

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

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

По-русски эту стадию называют прекращением применения и списанием. Так её именует ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем»: в приложении к нему как пример приведены шесть стадий жизни системы — замысел, разработка, производство, применение, поддержка применения и прекращение применения со списанием.

Как это делают, тот же стандарт расписывает по шагам. Цель процесса изъятия и списания он формулирует прямо — прекращение существования системного объекта. Для этого сначала определяют стратегию: что и в какой срок перестаёт работать, что будет с данными и оборудованием. Отдельно он требует заархивировать сведения, накопленные за время жизни системы, и записать знания людей, которые её сопровождали. Иначе вместе с системой из компании уходит и понимание, как была устроена эта часть работы.

→ Управление ИТ-активами. Тот же вопрос про любой ИТ-актив: учёт на всём жизненном цикле и решение о выводе и списании.

Что делать, когда поставщик снял продукт с поддержки

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

Что делают дальше, зависит от того, сколько осталось времени:

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

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

Откуда это взято: ASL и стандарт ISO

Свод знаний, который занимается управлением приложениями всерьёз, называется Application Services Library, сокращённо ASL. Его сделал в 1990-е годы нидерландский ИТ-провайдер PinkRoccade, в 2001 году свод открыли для всех, а с 2002 года его вёл фонд ASL BiSL Foundation. Действующая изданная редакция — ASL 2; карманное руководство по ней написали Иветте Баккер и Ремко ван дер Полс, издало Van Haren Publishing, второе издание вышло в феврале 2014 года.

Фонда больше нет: он в ликвидации с 19 октября 2022 года и распущен 31 декабря того же года, а права и издание перешли к Van Haren Publishing. Сам свод при этом жив — книги и экзамены продаются, третья редакция выставлена в бета-версии.

И редкая для сводов знаний деталь: у управления приложениями есть международный стандарт. ISO/IEC 16350:2015 задаёт требования к процессам управления приложениями, пригодные для улучшения, сравнения и подтверждения соответствия. Рядом лежит технический отчёт ISO/IEC TR 16351:2019, который сопоставляет главы ASL 2 с пунктами этого стандарта — по группам поддержки, сопровождения и обновления, связующим, управляющим и двум стратегическим.

Отсюда простое следствие для договора: требовать «соответствие ASL» нельзя, это свод практик, а не требования; требовать соответствие ISO/IEC 16350 — можно.

→ ASL — свод по управлению приложениями. Как устроен свод, что случилось с его владельцем и где взять первоисточник.

Как это выглядит в жизни

Как правильно и как не надо

Чем отличается от услуги

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

Разбор соседнего термина — услуга.

Чем отличается от технического долга

Технический долг — счёт, который набегает, когда раз за разом выбирают быструю заплатку вместо правильного решения. Это часть предмета, а не другое его имя: управление приложениями как раз и решает, гасить накопленный долг или дешевле вывести приложение целиком. Долг измеряют работой, которую всё равно придётся сделать; управление приложениями — решениями, которые приняли или не приняли вовремя.

Разбор соседнего термина — технический долг.

Чем отличается от цифрового продукта

Разница в том, что считают единицей. Приложение — конкретная система, которую можно установить, обновить и вывести из эксплуатации. Цифровой продукт — единица учёта в управлении ИТ: у него есть владелец, деньги и полный жизненный цикл, а приложение — одна из его составных частей. Одну и ту же учётную систему называют то приложением, то частью продукта — смотря о чём разговор.

Разбор соседнего термина — цифровой продукт.

Где встречается

Практики справочника, рядом с которыми живёт этот термин:

Своды знаний, в которых этот термин определён:

Что с этим делать здесь

Откуда термин

Application Services Library (ASL), редакция ASL 2: Yvette Backer, Remko van der Pols. ASL® 2 — A Pocket Guide. Van Haren Publishing, второе издание, 2014. Также ISO/IEC 16350:2015 и ISO/IEC TR 16351:2019; ITIL 4, практическое руководство «Software development and management» (AXELOS, 2020); ГОСТ Р ИСО/МЭК 15288-2005. Формулировка на этой странице своя.

Термины рядом