Клиенты, которые не обращают внимания на проблему “DevOps”, могут принести больше трудностей, чем денег

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

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

Это напряжение вызывает рост интереса к технологии управления жизненным циклом приложений (Application Lifecycle Management — ALM), представляющей собой набор средств управления, спроектированных с целью обеспечить программистам и сотрудникам ИТ-службы более ясное понимание сути разрабатываемого приложения и инфраструктуры, в которой это приложение должно выполняться. Основная идея заключается в том, что облегчение сотрудничества между разработчиками и ИТ-специалистами приведет к более эффективному функционированию всей корпоративной информационной среды. Проблема в том, что внедрение ALM имеет мало шансов в ситуации, когда две стороны, сотрудничество между которыми необходимо для обеспечения успеха проекта, начинают перекладывать друг на друга ответственность за возникающие трудности.

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

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

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

Версия для печати