Информационное проектирование по сю сторону Луевых Гор: пейзаж после битвы

Владимир Пржиялковский, по мотивам СофтМаркет, № 2/3, 1997


Срок беременности в человеческом обществе составляет 9 месяцев. На рождение этой статьи из моей головы, подобно как из Зевсовой при рождении, кажется, Афины, ушел 1 месяц май 1996 г. Возможно, что этот месяц должен соответствовать другому явлению природы, поскольку как раз 9 месяцев после него и ушли на толкание по редакциям, согласившимся бы открыто и свободно (как и пристало нашей свободной печати) опубликовать статью. В конце-концов, отважился журнал СофтМаркет, который обещал ее слегка подправить и показать автору перед подачей в номер. Первое обещание редакция выполнила, а второе -- не сумела. В результате большая доля текста сохранилась (это делает редакции честь), а меньшая -- или исчезла, или получила вставку того, что у меня как раз наоборот. Этому результату и обязано настоящее предисловие.

Сама статья родилась компульсивно, как реакция на опубликованную в апрельском, 1996 г., № ComputerWorld Россия статью Алексея Резниченко "Чья же страна Россия ?" и носила рабочее название "Алаверды, Алексей". Поскольку 9 месяцев были отданы не работе над статьей, а другой работе, степень разработки темы, увы, не явилась главным достижением. Поэтому сделаю пояснение. Основным тезисом полагалось, что потенциал разработок крупных информационных систем в России'97 (не путать с Россией'1897) отсутствует, и надолго, если не навсегда. Вести самостоятельные разработки можно лишь в области мелких и, отчасти, средних систем. Такая ситуация влияет на возможности проникновения в страну тех или иных СУБД, каковые и обсуждал в своей статье Резниченко.

Оригинальный текст, поданый в СофтМаркет, приводится ниже. Его (текст) разрешается перепечатывать и копировать без ограничений, целиком или частями, при условии отсутствия редактирования авторства.



Луевые Горы, помещенные в свое время фантазией Пушкина на Псковщине -- это, некоторый образ русской границы, и в этом смысле Россия окаймляется Луевыми Горами с запада и юга и омывается Луевыми Морями с востока и севера. Литва в "Борисе Годунове" -- отчасти образ заграницы, другого мира, да простят меня за возможную бестактность этого образа соотечественники, очутившиеся не в своей стране, не желая того. Нам, находящимся по сю сторону (фантастических) Луевых Гор, всегда интересно бывает разбираться с тем, что происходит у нас, соизмеряя это с происходящим по ту сторону. Это относится и к процессам, связанным с компьютеризацией, и, среди них, с использованием СУБД. О последних-то процессах в упомянутом контексте и пойдет речь в этих заметках (1).

Статей о разных СУБД в отечественных компьютерных изданиях появляется довольно много (можно, правда, отрезонировать, что меню однообразно), но, несмотря на это, описание общей картины происходящего в стране -- вещь чрезвычайно непопулярная. Видимо, исторически со статистикой дела у нас плохо (вспомним, например, о сложностях формирования статистических отчетов, что горячо обсуждалось, согласно Салтыкову-Щедрину, в (еще) прошлом веке на Международном статистическом конгрессе, проведенном, в знак признания мировых достижений Российской науки, в Санкт Петербурге; предметом особо активной дискуссии там стало волюнтаристское включение/не включение в статистические формы раздела, посвященного шпионам, радикально меняющего физиономию статистической справки в целом). Последнюю на моей памяти попытку рассмотреть общую картину (а более -- поставить вопрос) предприняла в апреле этого года статья под характерным заголовком "Чья же страна Россия ?", опубликованная в одном из компьютерных журналов (газет ?).

Выставление на обозрение публики пейзажа под названием "Распространение СУБД в нашей стране" (потребителе зарубежных технологий баз данных) -- достаточно деликатная вещь. Деликатность возникает сама собой из того, что (а) речь идет о рынке и (б) в этой области отсутствует не только монополия, но и отчетливо выраженное доминирование какой-либо СУБД. Отбросив экивоки, можно сказать, здесь замешиваются коммерческие интересы ряда крупных американских фирм, и рассматривать прихотливое переплетение их интересов объективно отечественная компьютерная пресса в целом не готова морально и/или материально. Обычно она показывает читателю всего лишь маленькие кусочки пейзажного полотна, к тому же трепетно отретушированные.

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

В отсутствии статистики (кстати, о "шпионах": а как насчет "пиратов" и других теневиков ?) остается только рассуждать о факторах, влияющих на распространение в стране СУБД: о внимании (зарубежной) фирмы-изготовителя данной (нашей) стране, о внимании к СУБД туземных купцов, об общих "складывающихся условиях" и "предпосылках" и пр. Это все связано между собой, но при анализе принято вычленять (любимый термин наших философов в пору моей учебы; по-моему, одним из самых радостных занятий для них было что-нибудь "вычленить"), и если вычленить самый объективный фактор (менее других субъективный), то это будет последний перед "пр.". Итак, какие именно общие предпосылки и условия влияют на распространение СУБД именно по сю, нашенскую, сторону Луевых Гор ?

Начать можно с downsizingа. Он относится к информационных систем вообще, но ясно, что "калибр" информационной системы должен соответствовать "калибру" применяемой СУБД. Здесь volens nolens будет сделана попытка обосновать тезис: Россия -- страна "даунов" в смысле "сайзинга", и это всерьез и надолго. Собственно, одна, главная подпорка для этого тезиса воздвигнута у всех на виду и не требует Диогенова фонаря для обнаружения.

Очистительный ветер перемен пронесся над страной, и унес с собой специалистов и технику. За считанные годы (раз -- два -- три !) Россия превратилась из державы "главных стоек" (mainfraimes) в "настольную" (desktop) республику. В стране, за небольшим исключением, просто не осталось физически крупных платформ; подавляющее большинство их бывших обладателей перешло в режим ожидания, когда N-тиум догонит "Пирамиду", или кого-нибудь еще. Проявив невиданный в других странах радикализм, Россия отказалась от главных стоек -- своих, а заодно и вообще. Как и следовало ожидать, со временем, все обнаружилось попятное движение -- большие машины стали покупаться за рубежом, но масштабы оказались несопоставимы с прежними. И здесь мы подходим к другой группе причин.

Крупные системы должны иметь с одной стороны своего заказчика, а с другой -- продавца, либо разработчика. Первое, что хочется уточнить: а есть ли у нас в государстве крупные заказчики ? Конкретнее: есть ли у нас потенциальные крупные заказчики, и есть ли у нас реальные крупные заказчики ? В первую категорию попадают те, кому по всем статьям положено иметь крупную компьютерную инфраструктуру: иначе не бывает на исходе текущего миллениума. Крупную ? это можно условно считать, поддерживающую работу с числом пользователей порядка 10000 или более, объемом БД более 200 Гб, с числом серверов более одного, и работающую в реальном масштабе времени.

В общем, это тема специального исследования, которым не здесь заниматься; важно заметить, что они есть, хотя и в чрезвычайно ограниченном количестве. Не то, чтобы совсем уж не осталось платежеспособных организаций: в масштабах страны их тоже немного, но абсолютным числом -- достаточно (2). Проблема в том, что в этом "дотаточном" числе "небольшого" количества организаций число реальных потребителей информационных систем невелико. Честно говоря, не приходят сейчас в голову примеры финансово крупных организаций, которым бы информационная система нужна была бы по существу. В том смысле, что критичным для их успешного существования и развития было бы совершенствование технологии и использование информационной технологии. Многим попросту нужно потратить деньги. Мне известно по меньшей мере две отечественные организации, пустивших в 1995 году на почве информатизации в ноосферу по 15 млн. долларов каждая. Примечательно, что обе они не являются государственными, а одна -- не специализированно финансовой. У меня нет ни желания (трое детей), ни возможности (н. с. академического института) эти примеры исследовать или множить, однако есть догадки, что они не единственные. Вероятно, что для большинства крупных организаций деньги производятся от их перемещения, или за счет более значительных факторов нежели совершенствование технологии работы.

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

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

Теперь о тех организациях, которые готовы, или "вроде бы готовы", внедрять у себя крупные информационные системы. Грубо говоря у них есть два пути: купить что-то существующее, или разработать специально для себя. Приобретение особенно тем, что практически однозначно это должна быть покупка зарубежной системы: своих крупных тиражируемых систем у нас попросту нет. Это влечет последствия. Поледствием политико-технологического характера является то, что зарубежные системы расчитаны на "западную" технологию (ведения расчетов, учета, производственных процессов и пр.) и нелокализованы (например, нерусифицированы). Первое могло бы расцениваться как преимущество, а не препятствие ко внедрению, но только не для крупных организаций. Крупные организации всегда консервативны, а многие из них, к тому же государственные, и поэтому на дивиденды от внедрения более совершенных западных технологий (если они имеются) естественнее расчитывать более динамичным средним или малым структурам. Вопрос использования русского языка (и прочих национальных признаков) в системе также ставится для крупных организаций достаточно однозначно: наши банки, в отличие от нидерландских, или даже немецких, существенно менее склонны внедрять у себя англоязычную систему, а госучреждения не склонны и вовсе.

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

Таким образом покупка зарубежной информационной системы не может сегодня служить путем активного распространения крупных СУБД в стране.

По другому сценарию организации могли бы заказывать разработки специально для себя ? не важно в данном случае, постороннему отечественному коллективу, или своему подразделению. Здесь картина менее прозрачная, а с другой стороны тема мне более близкая, поэтому позволю остановиться на ней подробнее. Оригинальность заказа разработки отечественному исполнителю (и своему, и постороннему) коренится в том, что мы в суматохе последних десяти лет выпали из мирового развития методологии, технологии и практики разработки крупных информационных систем, и, по большому счету, разучились такие ситемы делать.

Методология за время своего развития прошла три этапа, соответствующие т.н. "классическому проектированию", структурному проектированию и объектному. Классическое проектирование -- это строго последовательная схема проектирования системы, этап за этапом, так что переходы от одного этапа к другому четко выражены и материализованы, помимо программных и аппаратных компонент, еще и описательными документами. Предполагалось, что при пересечении границы между этапами вся проделанная ранее работа описана полностью в отчетах по предыдущему этапу, а весь объем оставшейся -- в задании на следующий этап (типа ТЗ). Классическое проектирование еще называют "каскадным". Оно практиковалось во всех странах, в том числе и у нас, будучи замечательно полно и подробно регламентировано, как многие помнят, ГОСТами.

Достоинства и недостатки классического проектирования давно известны; но здесь сейчас важно, что кроме первых имелись и вторые, и это заставило специалистов искать новые методы. Лет пятнадцать тому назад новым методом стало структурное проектирование. Структурное проектирование учитывало опыт классического, и в дополнение последнему предлагало целый ряд более гибких, или же вовсе альтернативных решений. Адресовались, например, такие проблемы, как сокращение сроков разработки -- в частности тогда, когда новую информационную систему предполагалось строить на замену существующей (слово reengineering, или "переделка/перестройка", тогда еще не эксплуатировалось), или проблема нечеткой постановки задачи заказчиком, а предлагаемыми решениями были, например, "радикальное проектирование", когда некоторые стадии проекта допускалось выполнять одновременно (например, допускалось одновременно приступать к программированию и составлению ТЗ на систему) или итеративно (с корректировкой ТЗ при повторном пересечении границ этапов), или же метод прототипирования.

Рабочим методом проектирования во всем мире десятилетие назад было классическое проектрование (в России/СССР постулированное ГОСТами), а структурное -- только разрабатывалось в академических кругах. И именно в это время пути расходятся: в других странах десятилетие было потрачено на то, чтобы сделать структурное проектирование реально используемым рабочим методом (что демонстрируется внушительным списком существующих сейчас CASE-систем, в той или иной степени поддерживающих эту методологию), у нас же все работы по теории и практике проектирования замерли, т.е. методологическим "максимумом" для нас осталось классический ГОСТовский подход.

Третий этап наблюдается сейчас: структурное проектирование, во многих случаях оказавшееся гораздо эффективнее классического, не стало "философским камнем" наших времен (косвенным свидетельством тому может служить то, что большинство CASE-проектов в мире и сейчас не оправдывает ожиданий), и активные работы по созданию новых методов концентрируются вокруг объектного проектирования. Ситуация сильно напоминает прежнюю: рабочими методами сейчас являются (в основном) структурный и (отчасти) классический, а объектный существует на стадии теоретических разработок, коммерческо-академических дискуссий и экспериментальных систем.

Как отмечалось, разработки крупных информационных систем и методологии создания таких систем у нас в стране прекратились примерно десять лет назад по причинам отнюдь не технологического или академического характера. Это же время было потрачено на производство методологического вакуума: многие из старых специалистов по методологии ушли в другие области деятельности, оставшиеся замерли на уровне работ "по ГОСТу", а новых попросту не появилось: книги по этой теме в стране не издавались и не переводились, а ВУЗовские курсы отсутствовали и отсутствуют. Слегка гипертрофированно положение можно охарактеризовать так: старые специалисты исчезли, или работают по устаревшей методологии, а новых нет, а значит и в ближайшем будущем не будет.

Технологическим воплощением методологических наработок являются в информационном проектировании в первую очередь CASE-системы. Время, когда такие системы начали появляться в экспериментальных вариантах -- пятнадцать -- десять лет назад -- еще не у всех стерлось из памяти. Можно вспомнить, например, на отнюдь не лишенную недостатков, но одну из первых отечественных, R-систему/технологию Института кибернетики АН УССР. Дальше в других странах Нового и Старого Света все развивалось своим чередом -- в других, кроме России/СССР, где практически все работы по этой теме прервались. Слово CASE робко появилось в начале 90-х годов для характеристики определенного класса западных продуктов (автор участвовал, вероятно, в одной из первых, если не первой, в стране закупке CASE-системы в 1992 году; это был Oracle CASE; нелегальных копий системы в это время не существовало, потому что никто не знал, зачем это нужно).

Именно этим временем датируется начало подмены понятий: CASE-системы мало-помалу проникали в страну как средство разработки больших информационных систем, и технологии, предлагаемые той или иной системой стали восприниматься как методология разработки (см. два абзаца выше). Это устраивало поставщиков CASE-систем, и здесь все сходилось. Если слегка гипертрофировать, то опыт работы с CASE у нас -- это чаще всего неумелый опыт работы с западными системами. Такой результат -- существенное ухудшение общемировой ситуации, итак в целом не очень благоприятной в отношении использования CASE: в мировой практике большинство CASE-проектов по-прежнему не оправдывают ожиданий заказчиков. Но все же, зарубежная практика гораздо чаще демонстрирует правильное использование CASE-систем: как инструментария для реализации применяемой методологии проектирования.

Практический опыт разработки крупных проектов зачастую не менее важен, чем методологический или технологический аспекты, и в любом случае необходим. Однако и здесь крупные разработки, доведенные до реального воплощения, встречаются не позже чем 10 -- 15 лет назад. Старых коллективов практически уже не осталось, а новые появляются только последнее время в новых русских компаниях, часто любящих называть себя системными интеграторами. Однако они, так же как и большинство новых русских компьютерных компаний, появляются "с нуля", на волне приносимой с Запада технологии (свято место пусто не бывает, и обвинять в этом иностранные компании нелепо; всем всегда были известны их интереы и правила существования), и при благоприятных условиях могут стать проверенно работоспособными коллективами только через несколько лет. Неблагоприятным условием может стать, например, ложно понятая методология (см. абзац выше).

Таким образом за последний период у нас не только исчезла практика самостоятельного создания крупных систем, но и исчезли необходимые условия для быстрого возобновления подобного рода работ при чудесном возникновении благоприятных промышленно-экономических факторов. "Строителям Империи" (выражение С. Моэма) это может быть и неприятно, но есть основания полагать, что способность разрабатывать крупные информационные системы своими силами исчезла в России если не навсегда, то очень надолго, и надежды на "возрождение" здесь почти что беспочвенны. Есть тому и исторические параллели: вместе со второй по масштабам волны эмиграции из России в нашем столетии, вызванной революцией 1917 года (первую по масштабам волну мы переживаем сейчас), страна потеряла строительную школу высокого уровня. Вслед за специалистами-носителями этой школы сама она переместилась в Югославию, сделав этой республике замечательную европейскую репутацию. Югославские строители вернулись на стройплощадки России/СССР уже в наши времена, и таким образом страна через десятилетия импортировала за деньги то, что подарила миру ранее. Советская же строительная школа, хотя и имела свои достижения, так и не достигла уровня качественного наполнения дореволюционной. Другой пример необратимости: нашей стране, похоже, уже не только создать своими силами операционную систему, но и не разобраться на приличном уровне в чужой -- последнее могут себе позволить лишь эмигрировавшие отдельные специалисты.

Можно было бы себя утешить тем, что с разработками крупных систем ситуация не радужная и в за рубежом. Многие известные специалисты, например Йордон или Де Марко, называют ее кризисной. Действительно, в чем мы не отстали от остальных за последние 10 лет, так это в разработке небольших приложений на малых платформах. Системы "быстрой разработки приложений" (RAD) стали популярными во всех странах, и формула "3 на 3" ("три наших специалиста сделают вашу систему за три месяца" на Clipperе, Foxpro и пр.) оказалась клише начала -- середины 90-х. Некоторые отмечают, правда тенденцию перехода к формуле "10 на 10", а особо прозорливые даже видят сквозь туман перспектив "30 на 30", т.е. возврат к характерным масштабам разработок 80-х годов, требующих в настоящих условиях крупную системную базу для разработки и для эксплуатирования. Различие в том, что по ту сторону Луевых Гор можно говорть о кризисе крупных разработок, а по сю сторону -- об исчезновении последних на неопределенный период времени.

Вот, собственно и все. Приведенные доводы могут свидетельствовать в пользу того, что единственная доступная ниша для информационных систем в России начиная с 90-х годов и на десятилетия вперед ? это малые и средние системы. Для работы в этой нише не нужны СУБД, требующие больше ресурсов, чем "Intel PC" (практически -- "Wintel"). В их категорию наилучшим образом попадают "персональные СУБД", СУБД, выросшие из персональных и СУБД среднего масштаба. В эту же категорию пытаются сейчас попасть СУБД, традиционно считавшиеся "большими". Примером является Oracle, долгое время справедливо считавшаяся большой и дорогой системой (до сих пор многие разработчики не ведают того, что Oracle сейчас предлагает дешевые и функционально почти что полноценные варианты СУБД для персональных платформ). Однако путешествие "от больших к малым" платформам не менее трудно, чем "от малых к большим", учитывая технические проблемы и то, что обе ниши уже заняты (при прочих равных долгое нахождение системы в определенном сегменте рынка повышает коммерческие шансы по отношению к вновь прибывшим). Путь же от средних информационных систем к большим, в свою очередь, так же проблематичен, как и в случае умощнения СУБД: ни одной из отечественных систем, несмотря на многократно выраженные намерения, пока это сделать не удалось (это отдельная тема для обсуждения; на мой взгляд и не удастся; есть помимо прочих и человеческий фактор, замечательно указанный в лишенной академических и романтических фантазий статье "Интегрированные системы как стадия в борьбе за ликвидацию человека" в "Мир Oracle" № 3/41 за 1996 г.).

Иными словами, таким системам как Sybase, Oracle или невинно пострадавшему от Российских реформ Adabasу, как представляется, есть и будет труднее, чем Interbase, SQL Server или Gupta. Хотя трудность и предопределение ? разные категории. Есть еще и субъективный фактор. Будущее, как отмечал революционер и гуманист Петр Кропоткин, приходит к нам из-за границы. Вопрос только, в каком виде оно переберется через Луевые Горы-Моря. Так что поживем ? посмотрим.


Примечания

(1) Они были написаны в мае а откорректированы в декабре 1996 г.

(2) Поясню, в каком смысле "много", а в каком -- "достаточно". Готовясь писать недавно небольшую заметку про Интернет, я натолкнулся на сообщение, что в США ежедневно прокладывается порядка 2000 км оптоволокна (через третьих лиц я попросил прокомментировать эту цифру одного из ведущих Северо-Американских "провайдеров", и получил ответ, что она правдоподобна). Это то, что можно считать в масштабах страны "много" (соответственно, наша аналогичная цифра -- чрезвычайно "мало"). С другой стороны, Россия сама по себе не маленькая страна, и денег от нефте- и газо-поставок вполне хватило бы на то, чтобы загрузить мощности орудующих в России фирм-поставщиков компьютерных услуг (если бы, конечно, "одни могли, а другие -- хотели"; см. дальше).