InfoWorld, США

На Коболе написан огромный объем кода. И есть действительно веские причины для развития таких приложений и использования их в современных архитектурах

Конечно, сегодня Кобол не пользуется популярностью, сравнимой с другими средствами разработки, такими как Java и .Net. Многие давно отнесли этот язык программирования к устаревшим технологиям. И тем не менее, как отмечает генеральный директор компании Micro Focus Стивен Келли, Кобол по-прежнему широко используется в корпоративном секторе. Micro Focus специализируется на модернизации приложений, в первую очередь написанных на Коболе. Келли, возглавивший Micro Focus в мае 2006 года, ответил на вопросы старшего редактора еженедельника InfoWorld Пола Крила.

Известно, что Micro Focus занимается в основном Коболом и модернизацией приложений, но в описании основных направлений деятельности компаний вообще нет упоминания о Коболе. С чем это связано?

Мы очень много делаем для ряда крупных корпораций. С нами сотрудничает около 90% организаций из списка Fortune 100, а во многих их решениях, так исторически сложилось, используется Кобол. Однако в последнее время, начиная примерно с 2005 года, возник большой интерес к нашим услугам по модернизации приложений: мы адаптируем приложения таким образом, чтобы их можно было использовать в современных информационных средах.

Насколько важен Кобол? Да, он используется довольно широко, причем давно, но мы о нем практически ничего не слышим. Мы слышим о Java, слышим о .Net и Visual Basic, но вовсе не о Коболе. Почему так происходит? Насколько распространен Кобол, какова его роль сейчас?

Вероятно, серьезные подвижки начались в связи с проблемой 2000 года, когда многие приняли решение отказаться от своих систем на Коболе, и в течение года-двух возник большой интерес к таким средствам, как Java. Однако в последние три года многие начали выражать свое недовольство таким решением, подчеркивая, что компании чрезвычайно успешно используют приложения, созданные достаточно давно и содержащие эффективные бизнес-процессы. Около 70% систем обработки транзакций в корпоративной Америке и Европе написаны на Коболе. На Коболе написан огромный объем кода. И есть действительно веские причины для развития таких приложений и использования их в современных архитектурах, для поддержки в них Web-технологий и преобразования их в Web-сервисы, чтобы они выглядели как современные приложения, иными словами, для защиты инвестиций в бизнес-правила, бизнес-процессы и код приложений. У нас очень много пользователей в отраслях розничной торговли и финансовых услуг, которые переносят свои системы, написанные на Коболе, с мэйнфреймов на современные платформы, подобные Linux или .Net. Они реализуют в этих приложениях поддержку браузеров, что позволяет сделать их интерфейс значительно более интуитивным, а не полагаться только на традиционную технологию «зеленых экранов».

Почему от Кобола отказываются в пользу Java и .Net? Дело в объектной ориентированности? Что эти языки дают такого, чего Кобол дать не в состоянии?

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

На деле все несколько сложнее. Очень многие Web-разработчики и Java-разработчики имеют опыт работы с разными языками. Если вы пишете на Java или на C#, то для того, чтобы начать писать что-то на Коболе, вам потребуется две-три недели. Некоторые крупные организации в США и Европе испытывают серьезное давление со стороны своих ИТ-руководителей, которые говорят, что, раз у них столько приложений на Коболе, в которые сделаны серьезные инвестиции, необходимо извлечь из этого как можно большую пользу. Если бы десять лет назад вы спросили ИТ-директоров во всем мире, они бы сказали, что в ближайшие пять лет намерены полностью отказаться от своих систем на Коболе. И тем не менее сейчас более 1 млн. разработчиков пишут на нем. И по-прежнему около 70% систем обработки транзакций в мире — это системы, использующие Кобол. ИТ-руководители стали более прагматично относиться к использованию разных языков, и они в значительно большей степени заинтересованы в том, чтобы модернизировать информационные системы своих предприятий, но при этом предпочтение отдают таким подходам, как SOA. Наконец, мало кто требует переписать системы на Коболе. Это уже было. Безусловно, когда мы столкнулись с проблемой 2000 года, тогда казалось, что через пять-шесть лет весь мир будет полностью объектно-ориентированным. Но надежды не сбылись. Большинство базовых бизнес-систем по-прежнему написаны на Коболе.

Я никогда не пробовал писать на Java или на некоторых более новых языках программирования. Но я когда-то писал на Коболе — еще в те времена, когда пользовались перфокартами, — и мне кажется, что это было достаточно просто…

Он логичен и относительно прост с точки зрения своей структуры. И я помню время, когда были перфокарты и я писал на Коболе, Фортране и Бейсике. Это было довольно легко, но, безусловно, наши программисты (у нас работает около 200 инженеров, и они все, как правило, пишут на Java, C++ и Коболе) в один голос утверждают скажут, что Кобол столь же легок, как и любой другой язык программирования, и его достаточно легко использовать.

Но сейчас ведь уже нет перфокарт, не так ли?…

По крайней мере, я их уже давно не видел. В свое время мы отдавали программу — в виде стопки перфокарт — на обработку, а результат получали через два-три дня. Сейчас все происходит несколько оперативнее. ИТ-руководителей сейчас все больше интересуют архитектурные вопросы, связанные с SOA и .Net. Мы же предлагаем надежные и уже опробованные приложения, но мы можем интегрировать их в современные архитектуры, подобные .Net. Вы получаете внешне очень современные приложения, поддерживающие работу с браузером, но основное ядро у них написано на Коболе. И в этой сфере работают многие из независимых производителей программного обеспечения и даже компании масштаба Oracle, которые используют продукты на Коболе в своих пакетах бизнес-приложений.

Не могли бы вы рассказать о вашей стратегии модернизации приложений и перехода на другие системы?

Самое главное — это идея модернизации. Мы занимаемся модернизацией в том смысле, что переносим основные приложения на современные архитектуры. Стратегия переноса на самом деле в первую очередь ориентирована на снижение затрат и увеличение эффективности за счет переноса некоторых приложений для мэйнфреймов на Linux или даже на Windows. Здесь нет выбора: многие начали переносить разработку приложений для мэйнфреймов на открытые системы. Кроме того, можно проводить все тестирование на открытых системах, а затем перенести скомпилированный код обратно на мэйнфреймы. Многие пользователи по-прежнему считают, что большие мэйнфреймы — это наилучшая платформа для систем обработки транзакций с действительно высокой производительностью, работающих круглосуточно семь дней в неделю и отличающихся высокой надежностью, готовностью и масштабируемостью. Но есть весомые причины для того, чтобы не использовать пакетный режим, а получать для своих разработчиков машинное время в определенный день. Поэтому они берут зеркальный образ приложения и ведут разработку в системе с Linux, тестируют ее здесь же, а затем переносят обратно на мэйнфрейм для, возможно, заключительного тестирования и последующего использования. Кроме того, они поддерживают целостность своих систем. Эта процедура позволяет сократить парк мэйнфреймов и добиться значительно более высокой готовности и пропускной способности в терминах разработки приложений.