Обсуждение

Спасибо, очень хороший документ, но есть баги. Самая, на мой взгяд, забавная: "Внешние интерфейсы ПО – те интерфейсы модулей программного обеспечения, по которым происходит коммуникация с модулями программного обеспечения, находящимия в ведении другого независимого системного администратора (например, в другом ведомстве, или в хозяйствующем субъекте). Внешние интерфейсы ПО должны быть специфицированы в явном виде и декларированы." "Внутренние интерфейсы ПО – те интерфейсы модулей программного обеспечения, по которым происходит коммуникация с модулями программного обеспечения, находящимися в ведении того же системного администратора. Внутренние интерфейсы рекомендуется специфицировать и декларировать." Своеобразно. Одним распоряжением Начальника Над Админами можно превратить внутренние интерфейсы во внешние (на самом деле, не только формально!). Никогда не думал, что интерфейсы ПО можно административно переподчинять. Пример того, как непоследовательность мысли вылезает в виде проблемы описания. //aen

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

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

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

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

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

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

Итак, вопрос оказывается лишь в том, что "пилотный" проект всегда "внешний" по отношению к любому окружению у функционального заказчика -- хотя бы потому, что формально его "начальник" из ФЦП, и report он людям из ФЦП сначала, и только потом функциональному заказчику. Договорились. Тут, правда, интересно, ежели один модельный или пилотный лот ФЦП бьется искусственно на много мелких кусочков из-за финансовых соображений (как это было в текущей волне конкурсов). Тут, наверное, специфицирование интерфейсов должно определяться волей архитекторов ФЦП, но при этом не нужно перебарщивать и требовать специфицировать детали внутренней архитектуры, ежели это неважно для являемых вовне интерфейсов. Ежели заявлено, что поддерживается NewsML, то внутри -- хоть на BizTalk его поддерживайте, хоть на JBoss, оба из которых прекрасненько могут выйти за пределы NewsML, только дай волю. А ежели обсуждать не чистоту реализации интерфейсов, а чистоту используемого инструментария, то можно скатиться к известному анекдоту про посадку за изнасилование всех подряд: аппарат-то есть ;) Нельзя забывать, что любой модуль модулен внутри. Переструктурированные программы -- печальное зрелище...

Конечно, вводить неразумные ограничения нельзя, кто бы спорил. С точки зрения обсуждаемых критериев что BizTalk, что WebSphere, что JBoss -- все едино, их специфические гадости выползают в других местах и там есть свои правила игры.