Разделы

Цифровизация ИТ в госсекторе

Электронное правительство РФ как система систем: новый сценарий

Тема создания электронного правительства волнует российское ИТ-сообщество уже несколько лет. CNews публикует исследование группы ученых — Юрия Акаткина, Владимира Дрожжинова и Валерия Конявского, рассматривающих e-goverment как систему систем. Авторы считают, что применение этого подхода разработчиками электронного правительства позволит построить действительно эффективную систему предоставления государственных и муниципальных услуг в электронном виде и наладить механизм ее работы. Мнение редакции может не совпадать с изложенной в статье точкой зрения.

Система систем реализуется в рамках программы из нескольких взаимосвязанных проектов, проектный офис каждого из которых управляет созданием, совершенствованием или сопровождением отдельной системы. Управление выполнением программы осуществляется в рамках офиса управления программой (Program Executive Office, PEO), связанного с проектными офисами всех систем, образующих целевую систему.

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

Различные виды интероперабельности в системе систем

Источник: System of Systems Interoperability, 2004

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

Система шин связи системы систем
(РЕО – офис управления программой, РМО – офис управления проектом, КБ – конструкторское бюро, ОО – офис оператора системы)

Источник: System of Systems Interoperability, 2004

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

Объединительные шины

Источник: System of Systems Interoperability, 2004

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

Получается, что для системы систем не подходят традиционные методы системной инженерии. Причины этого в следующем.

Во-первых, как показано, в системах систем имеют место три уровня взаимодействия. На каждом из них взаимодействуют люди и только на самом нижнем уровне – еще и системы. Для каждого уровня должен существовать соответствующий регламент документального, вербального и (или) визуального взаимодействия, которое может физически осуществляться по любому подходящему каналу – и через курьера, и по электронной почте или с помощью системы глобальной космической связи. Для поддержки взаимодействия менеджеров проектов, конструкторов и операторов систем в системе систем имеется широкий спектр соответствующих средств совместной работы. Вместе с тем не очевидно, что у целевой системы систем есть главный конструктор, который директивно влияет на принятие определенных решений по выполнению каких-то работ в системах, входящих в систему систем. Именно так обстояло дело с системой предоставления электронных государственных и муниципальных услуг электронного правительства России с 2002 до осени 2013 гг. Может, этим объяснялись постоянные переделки целевой системы систем.

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

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



* Edwin Morris, Linda Levine, Craig Meyers, Pat Place, Dan Plakosh. System of Systems Interoperability (SOSI): Final Report. – TECHNICAL REPORT, CMU/SEI-2004-TR-004, ESC-TR-2004-004, April 2004 – 67 p.

Linda Levine, B. Craig Meyers, Ed Morris, Patrick R. H. Place, Daniel Plakosh. System of Systems Interoperability Internal Research and Development Project/Proceedings of the System of Systems Interoperability Workshop (February 2003). – Technical Note CMU/SEI-2003-TN-016, June 2003. – 37 р.