От М-технологий к постреляционной СУБД Cache

Терри Рэгон: «Утверждение, что технологии развиваются волнами, стало трюизмом, но это так. Если какая-то компания не успевает за волнами, она погибает»

Компания InterSystems дважды проводила в Москве презентации своего флагманского продукта Cache, причем на вторую, состоявшуюся в мае, приехало почти в полном составе руководство компании. К сожалению, ни на презентациях, ни в непосредственном общении с сотрудниками московского представительства и фирм-партнеров мне никак не удавалось найти объяснение тому особенному месту, которое занимает InterSystems среди производителей СУБД. И, наверное, так бы и не удалось, если бы не посчастливилось в конце сентября по приглашению руководителей компании побывать в их бостонской штаб-квартире, побеседовать с ними с глазу на глаз и познакомиться с образом жизни InterSystems.

Встречам в Бостоне, по удачному стечению обстоятельств, предшествовала насыщенная поездка по Кремниевой Долине, что позволило сравнить работу InterSystems и других «программистских» компаний. Могу утверждать, что InterSystems действительно отличается от большинства программистских компаний (особенно молодых) пристрастным, я бы сказал культовым отношением к предмету своей деятельности. Этим, а не желанием поскорее вывести акции компании на биржу, детерминированы все стороны ее жизни. Может показаться странным, но не прибыль, которую можно получить на акциях, а совершенствование СУБД Cache является основным критерием деятельности для руководства компании и ее владельцев, совмещенных в одном лице. Они не стремятся, как подавляющее большинство небольших фирм, поскорее трансформироваться из частной в акционерную: в отсутствие внешних инвесторов компания более свободна на пути совершенствования своих технологий.

В InterSystems около 300 сотрудников, не так много, примерно столько же насчитывает средняя начинающая компания, каких в Кремниевой Долине сотни, если не тысячи. Но компания расположена не там, а в Бостоне — может быть, сегодня не первом по значимости, но исторически первом центре ИТ-технологий в США. Она занимает несколько этажей в здании, примыкающем к кампусу Массачусетсского технологического института, на той же набережной Мемориал-драйв, куда выходят основные корпуса этого крупнейшего научного и образовательного учреждения. Соседство далеко не случайно, а если учесть, что до другого не менее известного университета — Гарвардского — минут 15-20 пешком, то можно понять, что компания существует в атмосфере не только высоких технологий, но и высокого академического духа.

По данным аналитиков, компания уверенно занимает место в первой десятке производителей СУБД, в разных категориях она занимает места от шестого до десятого. На ее продуктах построено, по разным оценкам, от 2,5 до 3,5 млн. рабочих мест. При этом как марка InterSystems не столь уж известна. Нередко при упоминании ее имени, даже в профессиональных кругах, приходится услышать в ответ: «А кто это?» Казалось бы, странно, ведь у InterSystems есть офисы в 14 странах, разбросанных по всему земному шару, от Западной Европы до Новой Зеландии, и еще дистрибьюторы в десяти других. Парадокс имеет несложное, но необходимое для понимания ее специфики объяснение: на протяжении почти 20 лет InterSystems поставляла технологии управления данными, встраиваемые в прикладные системы. Так вот, оказывается, больше известны прикладные системы, ядром которых является продукция компании, чем она сама.

И еще: так сложилось, что среди вертикальных рынков, где она работает, основным был и остался рынок медицинских приложений. В США это значит очень много, там автоматизация офисной работы в госпиталях была и остается одной из важнейших задач. Медицинские системы достигают колоссальных масштабов; например, в госпитале, расположенном на противоположном по отношению к штаб-квартире берегу Чарльз-ривер, под Cache работает информационная система на 30 тыс. рабочих мест.

В 1997 году, набрав необходимые силы, InterSystems перестала быть поставщиком исключительно встроенных средств и вывела на рынок универсальную СУБД Cache. Сегодня IntеrSystems активно занимается пропагандой флагманского продукта, проводит остроумные маркетинговые кампании и, в струе современных тенденций, переименовала корпоративный сайт с тяжеловесного intersystems.com на модное e-dbms.com. Но внутри компания отличается заметным консерватизмом, обстановка ничем не напоминает то, что творится в быстрорастущих (а часто и быстро умирающих) фирмах «новой волны».

Рассказывать о впечатлениях, полученных в IntеrSystems, о потребительских качествах Cache нельзя, не представив основателя и главного действующего лица — президента и CEO Терри Рэгона. На его визитной карточке написано Phillip T. (Terry) Ragon, так и следует к нему обращаться — Терри. Он был и остается лицом компании, ее главным идеологом и разработчиком.

Генеалогические корни следует искать в М-технологиях. Мое первое знакомство с ними и языком MUMPS состоялось еще в середине 60-х. С тех пор и поныне моя профессиональная жизнь связана с идеями, появившимися вместе с М-технологиями. Замечу, что язык MUMPS приобрел особую популярность во всем мире в 70-е годы. Это объясняется тем, что он был поддержан DEC, перенесен на самый массовый компьютер того времени PDP-11 и получил известность под именем DSM-11.

Довольно быстро, точнее, через полтора года после окончания университета (Терри по образованию физик, закончил МТИ. — Л. Ч.), я пришел к выводу о необходимости создать собственную компанию и в этом качестве стать партнером DEC. Новая компания называлась IDX System. Она благополучно существует и поныне, являясь одним из крупнейших поставщиков программных продуктов для здравоохранения. В IDX я вел разработки, ориентированные на медицинские приложения, используя DSM-11.

Но в 1978 году вместе с партнером мы решили продать наше дело, в частности потому, что у меня созрело желание создать компанию, ориентированную только на системное программное обеспечение. Вот тогда и появилась IntеrSystems. На первых порах мы были заняты переносом MUMPS на другие платформы: на VAX, на персональные компьютеры. Нам вместе с партнерами из других компаний удалось создать многопользовательскую версию MUMPS, работавшую на ПК под управлением MS-DOS. Тогда же начался, точнее, я инициировал процесс централизации бизнеса, связанного с M-технологиями. До этого он был в нескольких руках, среди них, конечно же, DEC, моя компания, Micronetics и еще несколько.

Здесь я должен сделать отступление и объяснить логику моих дальнейших поступков. В рыночной борьбе два основных типа оружия: качество и стоимость продукта. Повышение качества всегда является положительным фактором, а вот снижение стоимости далеко нет — иногда это делается в ущерб качеству. В результате снижения стоимости компании начинают работать с такими малыми прибылями, что оказываются не в состоянии вести нормальную исследовательскую работу, а это приводит к ухудшению качества продуктов. Распыление сил между несколькими компаниями и «междоусобная» конкуренция ослабляли наше общее положение. Для того чтобы развивать новое поколение технологий, основанных на традициях М и MUMPS, не оставалось ничего другого, как консолидировать все силы и конкурировать не между собой, а с окружающим миром. Поэтому в 1993 году мы выкупили технологию DSM-11 у DEC, годом позже купили компанию Micronetics и стали практически монополистом М-технологий. Отношение коллег к тому, что я сделал, было неоднозначным, некоторые считают переход М в одни руки отрицательным итогом, но лично я уверен в том, что это наилучшее из возможных решений. Мы смогли развивать новую технологию на основе старой, и в этом я вижу главное достижение. Прошло всего несколько лет, и на свет появилась СУБД Cache, в которой совмещены лучшие из идей, проверенных временем, и наши новейшие достижения.

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

Проще всего сказать: «Благодаря качеству наших продуктов», но все сложнее. Да, мы всегда были уверены в качестве, но наших ресурсов не хватало на все, и мы постоянно уступали в маркетинге. Теперь мы пытаемся изменить это положение, вы видите, сколько внимания уделяется сейчас маркетингу и продажам. Должен вам сказать, что результаты есть.

Я хочу продолжить мысль, которая прозвучала в ответе на первый вопрос. Ведя бизнес, вам приходится постоянно решать почти инженерную задачу компромиссного выбора, а именно, как оптимально распределить усилия по двум фронтам: на совершенствовании продукта и на его продвижении на рынок. Вы можете по-разному расставить приоритеты в зависимости от целей и других обстоятельств. Что вам важнее — сам продукт или прибыль?

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

Приведу в качестве примера то, что произошло с одной из первых компаний, работавших в области баз данных; едва ли кто сегодня вспомнит ее название. А 30 лет назад у Cullnet не было конкурентов, ее лидерство было неоспоримо, но она упустила совершенствование продукта. Поэтому с появлением реляционных СУБД эта компания, не успевшая отследить изменения, бесследно растворилась в недрах Computer Associates.

Утверждение, что технологии развиваются волнами, стало трюизмом, но это так. Если какая-то компания не успевает за волнами, она погибает. Посмотрите на волну мини-ЭВМ. В 70-80-е было несколько компаний, успешно конкурировавших на этом поле. Кроме DEC, были и Data General, и другие. Все они погибали одна за другой, говорили, что их убивает DEC, но это неправильно, погибала технология, и DEC, как самая сильная, погибла последней.

Одна из таких технологических волн — подъем и неизбежный в последующем спад реляционных СУБД. Да, SQL был определенно хорош для своего времени, но его время уходит. Сейчас можно с уверенностью констатировать, что эта волна прошла свой максимум, но многие промышленные гиганты, поднявшиеся на этой волне, по сути, остановились в развитии ядра своих технологий. Смогут ли они отреагировать так, как следует? Поверьте, еще три года назад подобный разговор был совершенно невозможен, все были в полном восторге от реляционных СУБД, но волна, порожденная Internet, меняет технологический ландшафт, и впереди, как полагают многие, нас ожидают большие перемены.

И еще одно важное обстоятельство, обеспечивающее нам конкурентоспособность. Мы уделяем особое внимание процессу создания продукта. Мы не создаем больших команд, но делаем ставку на талантливые и продуктивные личности. Я считаю, что качество проекта определяется двумя людьми: лучшим, который устанавливает верхнюю планку качества, и худшим, который определяет нижнюю. Все, кто в середине, исправляют действия последнего. Это звучит сурово, но такова правда жизни.

Я никогда не отрывался от него, в зависимости от положения дел компании я отдаю ему от 30 до 50% своего рабочего времени. Чем лучше идут дела в компании, тем я свободнее и могу заниматься разработкой; мое участие определяется фазой проекта. Оно может быть ограничено архитектурными разработками, но когда дело касается обновления ядра системы, как, например, в Cache 4.1, я контролирую качество программирования с тем, чтобы обеспечить максимальное быстродействие.

Честно скажу, не знаю. У меня есть свои соображения на этот счет, но они носят отвлеченный характер. Общая беда всех современных программ заключается в том, что они слишком сложны, причем эта сложность не столько качественная, сколько количественная. Они представляют собой очень сложный инструмент, требующий скорее профессиональных навыков, чем фундаментальных знаний. Отчасти в этом повинна Microsoft. Она создала мир, в котором нужно много уметь, знать множество технологических приемов, но оставлено очень мало места, где можно приложить интеллект. Дальше этим путем пошли практически все.

Как следствие, мы становимся свидетелями удивительной ситуации. Студенту преподают в колледже курс computer science, где ему приходится изучать, скажем, теорию построения компиляторов, что-то связанное с искусственным интеллектом и тому подобное. Он получает неплохое академическое образование. Переходя к практической работе, он обычно обнаруживает, что ему приходится выполнять вполне рутинные операции, не требующие того фундаментального багажа, который он получил в процессе обучения.

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

Если же ограничить наш разговор базами данных, то следует отметить, что реляционные СУБД начались с того, что была принята концепция простой модели данных, на которую накладывается язык запросов. Это было очень перспективно в 80-е годы — тогда подразделения, обрабатывающие корпоративные данные, были отделены от пользователей буквально стеной. Они обладали всей полнотой информации, а доступ к ней для всех остальных был очень сложен. Тогда возникла острая необходимость в разделении доступа к данным между пользователями, имеющими персональные компьютеры на своих рабочих местах. Реляционная модель в сочетании с персональными компьютерами позволила быстро и эффективно разрешить это противоречие. Язык запросов оказался удобным инструментом, он открыл двери к данным всем желающим, поскольку не требует специальных знаний и очень прост. Реляционные базы стали универсальным средством для написания отчетов, в этом их главное достоинство. Но сейчас обнаруживаются определенные ограничения. Во-первых, такое ПО отлично работает до тех пор, пока данные не слишком сложны, а в последние годы постоянно возрастает сложность структуры данных. Поэтому первый барьер на пути реляционных СУБД — несоответствие простоты модели данных и сложности окружающего мира. Вторая беда в том, что работа с реляционными СУБД вырабатывает «транзакционный» стиль мышления, не всегда полезный, который распространяют на все и вся, даже на то, где он непригоден. Эти ограничения обнаруживаются при выходе за пределы корпоративных систем в мир Internet.

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

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

Эволюция M-технологий

Монополия уходит в прошлое