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

“Поверх задач”

К начинающемуся 22 октября в Лас-Вегасе очередному мероприятию DOES (DevOps Enterprise Summit)  «машина по производству DevOps-публикаций», издательство «IT Revolution Press» (например, DevOps Handbook, Gene Kim) выпустила публикацию «Преодоление неэффективности множества систем управления работами» («Overcoming Inefficiencies in Multiple Work Management Systems»).

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

(c) IT Revolution Press

Грубо говоря, есть разработка (с проектированием, тестированием и пр.) – тот самый «Dev». На картинке обозначен как жизненный цикл разработки систем (SDLC). Одной из фаз которого, кстати, является поддержка («Maintenance», в некоторых публикациях «Operations and maintenance»). Есть эксплуатация и поддержка («Ops»). Символом этого домена выбран (сюрприз-сюрприз) ITIL.

В каждом из этих доменов обычно используется множество различных систем, которые никак (или почти никак) не связаны. Это действительно проблема, поскольку теряется целостность картины и возможность сквозного управления. Тот самый поток (Lean, DevOps) становится непрозрачным (точнее, не визуализированным) и вообще не потоком, так как с точки зрения общей системы управления это отдельные фрагменты. Невозможно контролировать WIP. И вообще DevOps так не построить.

В общем, очевидно, нужно что-то делать. Ну, а решение-то какое?

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

Расходимся?

Или нет? Понятно, что принципиально подходов к решению данной проблемы существует немного. Для создания потока из «лоскутков» автоматизации, мы либо заменяем все системы управления на единую систему. Либо строим интеграцию. В том числе, как один из вариантов интеграции, реализуем надстройку.

Традиционный вопрос: «А как у вас?» Как решается данная задача? Предложенным вариантом решения пользовались?

«Трансформация ИТ в традиционных компаниях»
Учебный курс о кратном ускорении за счёт новой организации работы

Комментариев: 3

  • Леонид

    У нас Dev и Ops друг друга игнорируют. У Dev Agile и SCRUM, им надо чаще кидать на прод обновления, а то, что Орs каждый раз потом штормит пару дней от инцидентов, им плевать. Сквозного управления нет, взаимодействия и обратной связи почти нет.

    • Леонид, спасибо за то, что поделились!
      Как мне кажется, описанная ситуация, к сожалению, встречается нередко.
      Казалось бы, при чём тут манифест Agile (ну, тот, в котором “работающий продукт важнее…”)?
      Или продукт должен работать только среде разработки? 🙂
      И как насчёт Definition of Done?
      Простите, не удержался. Вопросы, разумеется, риторические.
      Надеюсь, заграница DevOps нам всем поможет. Но не тот девопс, в который на лету переобулись апологеты Agile и Scrum, подобные тем, о которых Вы написали, а правильный DevOps (который готовят правильные пчёлы :))

    • Вячеслав Алпатов

      “У нас Dev и Ops друг друга игнорируют. ” Тогда они не Dev и не Ops. Это же очевидно.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM