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

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

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

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

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

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

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