Лента

Открытые системы и тоталитаризм (ой, ну его, не могу больше)

Термин "открытые системы" становится все более и более распространенным. Сегодня трудно найти компанию, производящую программные продукты, которая не утверждала бы, что она является открытой. На слуху такие названия, как "Open VMS", "Open MVS", "Открытая архитектура Delphi", "Открытые средства CASE" и т.д. Все труднее становится понять истинный смысл подобных словосочетаний. Несомненно, в любом случае использование эпитета "Open" - в некоторой степени осмысленно, но суть его может быть разной.

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

Более того, все чаще раздаются призывы сделать использование стандартов абсолютно обязательным и проводить принудительную сертификацию программных продуктов, по крайней мере тех, которые предназначены для использования в государственных организациях. Другими словами, предлагается внедрение Открытых Систем традиционным для России чисто тоталитарным способом. Но, как известно, строгость российских законов смягчается необязательностью их выполнения...

Другая крайняя точка зрения состоит в том, что в подходе открытых систем должны полностью отсутствовать тоталитарные методы. Проектировщику, разработчику и программисту не должны навязываться какие бы то ни было обязательные действия и приемы. Компаниям-производителям программного обеспечения самим должно быть выгодно использовать стандарты, они должны сами осознать, что в этом случае получат более долговечные, проще сопровождаемые, повторно используемые продукты. Но откуда взять доверие пользователей? Почему я должен верить компании X, когда она утверждает, что ее программный продукт Y удовлетворяет международному стандарту Z?

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

Я представляю себе следующую примерную схему. Предположим, некоторая организация W (неважно, государственная или частная) хочет купить продукт Y, произведенный компанией X. Компания утверждает, что продукт соответствует стандарту (или профилю стандартов) Z, и достоверность этого факта критически важна для организации-покупателя. Тогда возможны два варианта.

Вариант 1: W полностью доверяет X (они сотрудничают уже 20 лет и не было ни одной промашки). В этом случае организации W не требуется сертификация продукта Y, но компания X тем не менее не может провести такую сертификацию, дабы еще больше утвердить свою репутацию.

Вариант 2: W не доверяет X. Тогда организация W может поставить в качестве условия приобретения продукта Y его обязательную предварительную сертификацию. Компания X должна оценить, что для нее выгоднее - потратиться на сертификацию или отказаться от сделки с W.

Казалось бы, все тривиально и разумно. Никакого тоталитаризма, а лишь разумный государственный контроль (чтобы налоги платили). Благодать... Но сразу возникает вопрос, кто и как будет производить сертификацию?

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

Итак, что мы имеем в виду под сертификатом на соответствие программного продукта некоторому стандарту или стандартам? Это документ, выдаваемый сертифицирующей компанией Q после тщательного обследования программного продукта. Это сертификат именно компании Q, которому можно доверять или не доверять. Организация W, покупающая продукт компании X, может, в конце концов, потребовать его сертификации в конкретной сертифицирующей компании Q*. Неплохо было бы иметь закон, позволяющий преследовать в суде компании, выдавшие липовые сертификаты (хотя, как отмечалось выше, любой прокол означал бы крах такой компании).

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

Ну и наконец, подумаем о том, как собственно производить сертификацию. Вообще-то, это дело сертифицирующей компании. Если ей верят, а она не обманывает, то покупателю глубоко безразличны методы, используемые его любимой компанией Q*. Однако, как всегда, есть по крайней мере одно "но". Представим себе, что компания-производитель X действительно образец честной компании, желающей произвести программный продукт, соответствующий стандарту Z. Было бы глупо соваться в компанию Q* до тех пор, пока специалисты компании X сами не удостоверятся в соответствии стандарту. Так что, господа, нужны не только политические, но и технические решения.

Казалось бы, здесь-то нам проще. Но именно инструментальные пакеты, проверяющие соответствие программы указанному стандарту, - основная проблема массовой сертификации программных продуктов. Во-первых, их трудно создавать. Во-вторых, как доказать, что пакет действительно правильно работает? В-третьих, как обойтись без таких пакетов? Они нужны и производителям, и сертификаторам, и пользователям... Однако, как говорили братья Стругацкие, это уже совсем другая история... (В конце концов, хотя эта страница и последняя, я надеюсь, что это не последняя моя страница.)