Хороший стандарт — незаметный стандарт

Выпускник Массачусетского технологического института, Соули работает в Object Management Group с момента ее основания в 1989 году, начав карьеру с технического директора группы первоначальной версии спецификации CORBA (Common Object Request Broker Architecture), ставшей своего рода визитной карточкой OMG. В середине 90-х Соули возглавил работы OMG по разработке отраслевых стандартов для различных индустрий, а также процессы стандартизации в области моделирования — языка моделирования UML (Unified Modeling Language) и затем архитектуры на базе моделей MDA (Model-Driven Architecture).

— Можно ли структурировать направления деятельности OMG и выделить ключевые стандарты, над которыми сейчас ведется работа?

Сегодня членами OMG являются более 500 организаций, 4 тыс. человек участвуют в нашей работе, в данный момент разрабатываются около 100 стандартов, а за 21 год работы OMG выпустила почти тысячу стандартов.

Работу по стандартизации мы делим на два направления. Первое — это платформа. Сюда относятся стандарты моделирования, такие как UML, SysML, BPMN, стандарты связующего ПО — DDS и CORBA, стандарты для встроенных систем и систем реального времени, стандарты обеспечения отказоустойчивости и др. Одна их основных работ OMG gо этому направлению – новый стандарт CISQ (Consortium for IT Software Quality) для измерения качества ПО. Наиболее значительно второе направление — стандарты для различных вертикальных рынков. В OMG образованы 25 рабочих групп, которые занимаются стандартизацией для финансовой сферы, производства, транспорта, здравоохранения, для интеграции военных систем, средств военных коммуникаций и др. Примерами их работы может быть стандарт MDMI (Model Driven Message Interoperability) для коммуникаций между финансовыми платежными системами, стандарт для управления медицинскими записями, разработанный совместно с HL 7, международной организацией по стандартизации в медицине.

В целом очень трудно выделить какое-либо одно направление нашей деятельности, и если говорить о наиболее известных, то это стандарты моделирования, такие как UML — стандарт номер один для моделирования в разработке программного обеспечения, BPMN — стандарт номер один для моделирования бизнес-процессов, SysML — ведущий стандарт для моделирования в системной инженерии для крупномасштабных проектов, например в авиастроении.

Около половины членов OMG — это производители программных продуктов, как крупные, например IBM, HP, Microsoft, так и небольшие — Adaptive и др. А другая половина — это пользователи ПО, такие как General Motors, операторы связи, производственные компании, банки — Wells Fargo, HSBC. Объединить их вместе — значит дать возможность создавать стандарты, которые будут применять пользователи программных продуктов и которые будут реализовывать производители ПО. Поэтому нашими партнерами по разработке CISQ являются поставщики ПО, интеграторы программного обеспечения, пользователи ПО, специалисты по метрикам ПО.

— Каковы этапы жизненного цикла стандарта?

Первый шаг – собрать участников разработки, найти компании и людей, которые заинтересованы в создании стандарта. Затем разработка требований, выбор решения. На этапе финализации первые реализации стандарта используются для поиска проблем в спецификациях. И затем каждые два года происходит цикл ревизий стандарта с целью удостовериться, что стандарт по-прежнему удовлетворяет потребностям пользователей и производителей. Для некоторых стандартов наступает этап вывода из употребления – sunset в нашей терминологии. Но пока таких стандартов немного. Знаете, как я определяю унаследованные системы? Унаследованная система – это система, которая работает. Это действительно так. Большинство программных систем до сих пор находятся в рабочем состоянии. Они обновляются, модернизируются, но не выводятся из употребления. Мы прекратили действие нескольких устаревших стандартов, например первоначального OpenDoc, предложенного Apple. Но большинство наших стандартов продолжает использоваться.

— Какие могут быть причины для вывода стандарта из употребления? И не произошло ли это сейчас, например, для CORBA?

Если у вас есть мобильный телефон, значит, вы повсюду носите с собой CORBA. Около 4 млрд копий CORBA работают именно в этот момент, когда мы с вами разговариваем. Каждый мобильный телефон, каждая среда разработки на Java, каждая виртуальная Java-машина, каждый робот, каждый коммутатор у оператора связи – все они оснащены средствами CORBA. CORBA жива, и ее применения особенно успешны во встроенных системах реального времени. Несколько лет назад в OMG был выпущен стандарт, развивающий возможности CORBA, – Data-Distribution Service, который использует очень многие функции CORBA, реализует механизм коммуникаций по принципу «публикации-подписки» в реальном времени и пользуется большой популярностью в банковских и военных системах.

Но есть стандарты, которые прекращают свое действие. Это происходит, когда о них больше нет никаких новостей, что означает, что они больше реально не используются. Существует определенный процесс для «утилизации» стандарта, но более интересен процесс поддержки стандарта в течение времени. Мы поддерживаем CORBA почти 20 лет и будем продолжать поддерживать, пока эта архитектура используется. На самом деле хороший стандарт – это стандарт, который не заметен.

— Что собой представляет инициатива Business Ecology Initiative, которую также продвигает OMG?

Несколько лет назад мы выяснили, что члены OMG заинтересованы в совместной работе не только для создания стандартов, но и для выявления и описания лучшего опыта в разных областях. Так появился SOA Consortium, перед которым была поставлена цель способствовать внедрению сервисной архитектуры в максимальном числе организаций к концу 2009-го. И мы добились этого — в конце 2009 года более 75% компаний, входящих в список Global 2000, сообщили, что успешно реализовали SOA.

Мы поняли, что должны обобщить этот опыт, и сейчас под эгидой OMG организовано четыре рабочих группы, или «сообщества практиков» (Community of Practice): по управлению бизнес-процессами и SOA, по кибербезопасности, по «зеленым» технологиям и по обработке событий. Эти группы не занимаются стандартизацией — их объединяет поиск ИТ-возможностей, открывающих путь для оптимизации бизнес-процессов, которую мы называем оптимизацией для инноваций. Один из способов такой оптимизации – автоматизация бизнес-процессов, но есть и множество других. Каждая из этих групп ищет свои пути формирования  «экологии» бизнеса: как убрать лишние расходы, связанные с реализацией бизнес-процессов, как перестать дублировать бизнес-процессы, как справиться с избыточным расходованием воды, бумаги и других ресурсов. То есть добиться оптимизации бизнес-процессов, которая обеспечит новые возможности для развития бизнеса. В этом суть Business Ecology Initiative.

— Почему именно сейчас возникла потребность в стандарте CISQ?

Каждый внутренний или аутсорсинговый проект по разработке ПО должен иметь определенные метрики качества программы — только так у заказчика будет возможность принять результаты проекта, и особенно это актуально для аутсорсинга. Однако сейчас нет стандартов на артефакты разработки, поэтому для каждого контракта на разработку ПО приходится снова и снова задавать свои критерии приемки, включая критерии качества. Это глупо. Ведь мы знаем, что составляет высокое или низкое качество разработки, так почему же не закодировать это знание и не сделать автоматической проверку качества программного кода?

На сегодняшний день большинство критериев приемки программного продукта не автоматизируемы. Как правило, мы даем код кому-нибудь очень умному, он смотрит и выносит свой вердикт. Проблема в том, что эти критерии неповторяемы (каждый раз придумывается что-то новое), они не вполне справедливы с точки зрения контракта, поскольку только одна сторона принимает решение, и, в конце концов, они дорого обходятся, если оказываются необъективными. Устранить эти недостатки и добиться выполнения раз и навсегда заданных критериев качества на протяжении всего проекта возможно только при наличии стандартов.

Год назад мы разработали стандарт для метамоделей кода — Knowledge Discovery Meta-Model (KDM), который изначально предназначался для модернизации программного обеспечения. Мы берем, например, код на Коболе, выясняем, что этот код должен делать, фиксируем это в модели KDM и затем генерируем с ее помощью код на Java или каком-либо другом современном языке программирования. Эта же база знаний KDM может использоваться для многих других задач, например, она применяется в нашей инициативе Software Assurance по анализу и обмену информации о достоверности ПО. И на нее опирается автоматизация метрик качества программного кода, предлагаемая в стандарте CISQ. Если мы будем разрабатывать метрики качества ПО отдельно для Фортрана, C++, Паскаля, Java, C# и т. д., то потратим вечность на создание такого стандарта. Но если сделать это один раз в KDM, то для любого языка программирования, который имеет внешний интерфейс KDM (а его имеют все языки), можно измерить значение метрик качества.

— Работой над стандартом CISQ помимо OMG руководит Институт программной инженерии (Software Engineering Institute) Университета Карнеги-Меллона. Почему?

Очень часто задают вопрос: «Зачем нужен стандарт CISQ, если уже есть CMMI и можно использовать эту модель как стандарт качества программного обеспечения?» Однако модель зрелости CMMI, разработанная в SEI, не измеряет качество программного продукта, а позволяет измерить качество процессов разработки ПО. Она показывает, например, происходит ли постоянное совершенствование процесса, является ли процесс согласованным, но ничего не говорит о результатах разработки. А CISQ измеряет программный код продукта. Это не означает, что теперь можно игнорировать процессы, но вы не должны игнорировать и артефакты разработки. Если, применив стандартные метрики качества, вы обнаружите, что получаете плохие артефакты разработки, возможно, вам захочется понять, каким образом надо улучшать процессы. Если процесс соответствует третьему уровню модели CMMI, но при этом качество кода очень низкое, возможно, ваш процесс на самом деле имеет серьезные недостатки. Таким образом, необходимо анализировать и то и другое. В SEI хорошо понимают, что нужны как технические метрики программного продукта, так и метрики динамики процессов разработки ПО.

Если у вас согласованный процесс, который постоянно приводит к созданию плохого продукта, значит, надо менять процесс. Здесь налицо обратная связь от CISQ к CMMI. Если у вас формально нет согласованного процесса, но результатом разработки является ПО высокого качества, другая обратная связь будет состоять в том, что, возможно, вам стоит зафиксировать такой процесс, потому что он дает отличные результаты. Если у вас продукт низкого качества, то, возможно, вам стоит обратиться к СММI, чтобы усовершенствовать свой процесс. Таковы возможные взаимосвязи между CMMI и CISQ, и мы совместно с SEI работаем над тем, чтобы отразить их в стандарте.

— Какие еще проблемы в области программной инженерии вы видите?

В программной инженерии сегодня доминируют мода и сиюминутные увлечения. Что выбрать – объектно-ориентированный, компонентно-ориентированный либо сервисный подход? Честно говоря, этот выбор чем-то напоминает мне моду на длину юбки. Такой подход возможен в области свободных искусств, но неприемлем для инженерной дисциплины. Одна из причин такого положения вещей состоит в том, что мы не используем согласованную методологию во всех проектах разработки ПО.

Если я попрошу вас сравнить ХР и RUP, вы не сможете это сделать объективно. Вы скажете, что один метод больше концентрируется на документации, а в другом используется принцип парного программирования. Все это сложно сравнивать, однако если мы посмотрим повнимательнее, то увидим, что все процессы имеют сходные основы, базовые практики, фактически одинаковые для любых процессов. Например, нужна команда разработки. Использует ли она RUP, XP, Scrum – не самое важное, но это должна быть команда.

Вместе с Иваром Якобсоном и Бертраном Майером мы попытались выявить базовые универсалии разработки, присутствующие во всех методологиях, а также язык, с помощью которого эти универсалии формируют методологии. Это даст возможность сравнивать разные методологии и строить собственные, учитывая уже существующие практики. Так возникла инициатива SEMAT (Software Engineering Method and Theory). Пока это не работа по стандартизации, но нас уже поддерживают почти полторы тысячи человек, среди них ведущие специалисты по программной инженерии из университетов Германии, CША, Швеции и Франции. Мы работаем вместе в поисках путей идентификации таких универсалий. Если это нам удастся, то следующим шагом будет стандарт.

— Что вы думаете о современном состоянии обучения в области компьютерных наук?

Большинство университетских программ по программной инженерии в мире можно отнести к одной из трех основных категорий. Некоторые концентрируются на преподавании абстрактных понятий, вопросах контроля сложности и управления большими проектами. Другие — на теории, предлагая студентам обширную математическую базу, основы компьютерных систем и программного обеспечения. Но наиболее значительная часть вузов фокусируется на «механике»: алгоритмы, языки программирования, структура системы команд, разработка баз данных, специальные языки программирования и т. д. Очень жаль, что таких программ обучения подавляющее большинство. Они не учат студентов быть первоклассными разработчиками, а готовят «дворников», разработчиков низкого уровня, которые не понимают сути разрабатываемых ими систем. Я считаю, что это наиболее распространенная ошибка вузовского обучения.

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

Российские университеты считаются лучшими в мире по преподаванию математики и вычислительной теории. Это фундаментальные основы, знание которых крайне важно для разработки определенных типов приложений. В Индии из вузов ежегодно выходит 300 тыс. специалистов в компьютерной области, в Китае на 250 тыс. больше, и Россия, как и США, в этом плане не могут с ними конкурировать и должны искать свою нишу. Если говорить о России, то такой нишей являются сложные системы, системы реального времени, их реализация с высоким качеством и в заданные сроки. Для такого рода характеристик хорошая теоретическая база играет важнейшую роль. Преимущества американских университетов — умение выпускать предпринимателей и креативщиков, генерирующих новые идеи. Таких людей много и в России — конференция SECR¹ убедительно об этом свидетельствует. Ниша для Индии и Китая на ближайшее будущее — выпускать десятки тысяч кодеров, которые смогут реализовать ваши идеи.

— Что вы можете сказать об уровне китайских программистов?

У меня есть опыт преподавания в одном из университетов центрального Китая — у китайских программистов хорошая теоретическая база и мало практического опыта, но ситуация быстро меняется. Они охвачены огромным энтузиазмом в отношении развития этой области, например, в Пекинском университете сегодня одна из лучших в мире учебных программ по компьютерным наукам и там работают ведущие специалисты со всего мира.

— Какие стандарты необходимы для облаков?

Более 90% из того, что сейчас публикуется об облаках, — это хайп (маркетинговая шумиха). Но остальное — правильная и важная информация. Облака имеют огромное значение, особенно для стартапов, которые не могут позволить себе иметь собственную ИТ-инфраструктуру. А с помощью облаков они сразу получают работающую инфраструктуру. Им не нужно покупать все и сразу, не нужно одалживать для этого большие деньги, не нужно развертывать ЦОД. Это можно сравнить с арендой автомобиля — если я найму машину на год, это дороже, чем купить и использовать ее в течение года. Но зато мне не нужно иметь всю стоимость машины в момент найма.

Что нужно для того, чтобы сделать практику использования облачных сред успешной для маленьких компаний и для крупных пользователей? Необходим общий способ представления исполнимой нагрузки. На самом деле для решения этой задачи организацией Distributed Managament Task Force (DMTF) уже разработан стандарт Open Virtualization Format. Прекрасный стандарт, остается только его использовать. К сожалению, не все провайдеры облачных сервисов поддерживают OVF. Насколько я знаю, поддерживает Amazon, но не поддерживают Google и Saleforce.com.

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

В настоящее время порядка 12 организаций по стандартизации работают в области облачных вычислений, и OMG занимается координацией их деятельности. Каждые две недели происходят виртуальные встречи, которые позволяют всем этим организациям иметь представление о том, что делают другие. Есть специальный сайт cloud-standards.org, на котором перечислены направления работы каждой группы.

— Какие вы видите тенденции в ИТ, которые могут привести к появлению новых стандартов в будущем?

Есть два основных фактора, влияющих на процессы стандартизации в ИТ. Во-первых, необходимость создания качественных стандартов, которые предотвратят пустую шумиху в отношении новых технологий. Я начинал свою карьеру в области искусственного интеллекта, и никто тогда не контролировал очковтирательство в этой сфере. Люди надеялись построить компьютер, который будет думать, и известно, что из этого вышло. Нам удалось справиться с шумихой в отношении распределенных объектных технологий и моделирования в начале 90-х годов. Мы занимались этим по отношению к SOA и делаем это сейчас применительно к облачным технологиям.

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

Сейчас мы обсуждаем с автопроизводителями возможность создания стандарта в области дизайна и проектирования автомобиля и его компонентов. Думаю, через некоторое время такой новый стандарт появится. Автомобильный рынок меняется, появляются новые крупные игроки, такие, как, например, Tata, Chery. Это хороший момент для того, чтобы собрать всех вместе и договориться о вещах, которые до сих пор были несовместимы.