?

Log in

No account? Create an account

Previous Entry | Next Entry

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

A. Речь идет о системе межведомственного электронного взаимодействия. О ней уже я писал tri-botinka.livejournal.com/7978.html

Это довольно популярное решение - зовется J2EE ESB см soa.sys-con.com/node/39767
Но более интересны разработки метамоделей на транспортную шину, реальные форматы объектов и их отношений. про это можно почитать здесь dublincore.org/ вот здесь www.oegov.us/ вот здесь www.semic.eu/semic/view/snav/assetRepository.xhtml или здесь epractice.eu/

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

Q. А чем отличается СМЭВ от ОАО "Ростелеком" от "ихнего" СМЭВ ? Ведь в рамках ОГИЦ уже это делалось ?

Н-даа,  вопросы ставить легко - отвечать трудно.  Юридически мне понятно. В постановлении Правительства Российской Федерации от 25.12.2007 № 931 "О некоторых мерах по обеспечению информационного взаимодействия государственных органов и органов местного самоуправления при оказании государственных услуг гражданам и организациям" были описаны конкретные цели создания ОГИЦ - "В целях обеспечения информационного взаимодействия федеральных органов исполнительной власти, органов исполнительной власти субъектов Российской Федерации, других государственных органов и органов местного самоуправления при предоставлении гражданам и
организациям государственных услуг с использованием телекоммуникационных технологий"

Т.е. основная цель - информационное взаимодействие ОРГАНОВ ВЛАСТИ.  А СМЭВ создана для обеспечения обмена информацией между ИНФОРМАЦИОННЫМИ СИСТЕМАМИ. Разницу чувствуете ?   Конечно, казуистика простому гражданину непонятная, но юридические тексты пишутся именно таким языком - который подразумевает только прямой смысл и никаких "если", "может" и других догадок.

Но есть различия и в идеологии. Если ОГИЦ по сути представляет собой мега-вычислительный центр, в котором просто территориально физически сосредоточены ведомственные ИС, то СМЭВ по сути подчеркивает - что никакой центральной системы нет и быть не может - многие системы равноправны и строить нужно распределенную систему, в которой существует много альтернативных способов обмена информацией, множество маршрутов доступа и даже (о нет !)  отдельные локальные политики обмена и обеспечения безопасности, отличающиеся от друг от друга.

Согласен что идея "централизма" хорошо усваивается нашими чиновниками и ложится на наш византийский стиль управления. Это так просто и понятно - выбрать одного "царя горы" - хозяина ресурсов и потребовать от него отчетности за всех.  (раньше говорят так и улицы строили - "елочкой" - и старший по налогам было - тот, кто жил у самого корня. проблем не было подати брать - перекрыл единственную улицу - и все как миленькие заплатят).  Однако юридически возникают коллизии - до сих пор нет ни одного министерства, обладающего полнотой власти - приказывать другим то-либо делать в межотраслевых нишах. Ну не может Минкомсвязь приказать использовать определенные ИТ технологии - пожурить может, а запретить нет. Не может Минфин заставлять укреплять нац.валюту и не работать в долларах, не может Минобранауки заставить других писать слово "кофе" в среднем роде..
Я понимаю лозунги "централизма" - но даже не глубоко копая - можно понять что цель этого лозунга - выбить себе бюджет "за всех" , но не отдать его дальше "для всех". В итоге аппологетов ОГИЦ все равно задвинули не лезть в задачи административной реформы (еще один "долгострой"), вопросов федерального и регионального законодательства и настоятельно - шаг за шагом задвинули в узкие рамки обеспечивающей инфраструктуры. Построили вычислительный центр - ну и сидите тихо.
А ВЦ получился кстати неплохой - по уровню tier-5 (по-моему) - но объяснить зачем должен крутиться какой-нибудь портал управленческих кадров на железе, способном выдержать чуть ли не прямое атомное попадание (и столько же стоящем) получается неуверенно.
Но я думаю ничего из ОГИЦ не пропало, как бы ни расползались слухи - ИТ-шники люди такие - им сколько ни дай ресурсов - все мало будет. Поэтому произойдет разумная переоценка полезности ресурсов , возможно появятся и понятные коммерческие заказчики и ресурсы ОГИЦ полностью вольются в инфраструктуру российского электронного правительства .

А вот СМЭВ от этих недостатков "централизации" архитектурно избавлена. И содержит технологии мягкого эволюционного развития. Вместе с тем - SOA (на которой основана СМЭВ) весьма странная архитектура. На сегодня количество решений в такой парадигме не так велико, как кажется.  По сути это сродни полету на Луну.  Есть инструменты, есть технологии, есть люди, и даже были успешные прецеденты - однако массово это не повторимо.

Почему ? Обычный вопрос - а кто за это заплатит ? В написании бизнес-сервисов принимают участие уже не один - а 5 специалистов разной компетенции - главный аналитик по продукту, бизнес-аналитик, системный аналитик, системный архитектор, проектировщик (если будет интересно - расскажу отдельно про "высокоуровневую" технологию разработки в SOA) 

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

Вот здесь - Ростелеком (на мой скромный взгляд) может избрать понятную для себя тактику - за написание "SOA-софта" должен платить владелец "железа", а тот получать эти деньги за счет функциональных заказчиков во всех городах и весях России. Поэтому возможной стратегией станет установка ДАТАцентров и добровольно-принудительной посадкой на них абонентов. Взимать плату станет просто - "а не будут брать, отключим газ и воду !", но как и в каждом перекрестном софинансировании проблемы останутся. Только теперь проблемы деления "вершков и корешков" из внешнего сектора независимых пользователей и спонсоров перетекут внутрь Ростелекома. Как там будут делить доходы админы, телекоммуникационщики и программисты - решать их руководству. Догадываюсь что внутренняя кухня будет далеко не стерильной. В итоге программисты будут довольствоваться маржой 10% (что для железячников манна небесная), но привыкшие к 30% марже интеллектуалы ассемблера и фрилансерства - быстро просекут фишку и свалят. То есть такой подход подломит стабильность внутреннего управления и по сути не будет стимулирующим для софтописания.

Другой подход к SOA ( и в принципе многие страны так и живут) - уход в чистую сервисную нишу - облачные вычисления, SaaS и пр. Т.е. создается механизм предложения массы уникальных авторских сервисов, механизм доставки автору роялти за пользование - и дальше пусть Природа делает свое дело. Но это небыстрый процесс, и модерироваться он должен не командными окриками, а убеждениями, компетенцией, "проповедями", стандартами и неформальным лидерством. Получается что нужно по сути строить свое комьюнити и заниматься не только техническими вопросами, но и социально-организаторскими. Тактически это дешевле - достаточно взять в штат 2-3 харизматических "звездочек" и пусть это начнет обрастать по типу Web 3.0 знаниями - однако как это объяснить Первым лицам - ума не приложу.

Q. И все же - какие финансовые преимущества даст СМЭВ (SOA) ? Конретно !

А. Мировой опыт дает следующие качественные изменений (в % опрошенных, которые заметили результат - по убыванию)

1. Разработка новых бизнес-процессов ( 50%)
2. Уменьшение сложности ИТ ( 44% )
3. Повторное использование сервисов ( 40%)
4. Сближение с бизнесом ( 37%)
5. Ускорение цикла внедрения ( 27%)
6. Оптимизация затрат на интеграцию ( 24% )
7. Синхронизация данных в ИС ( 21%)
8. Оптимизация эксплуатационных затрат ( 20%)
9. Управление бизнес-процессами (17%)

Q. Послушал СМЭВ от Ростелекома - не вдохновило. А какие вообще бывают заблуждения относительно SOA ?

A. Достаточно. Например построили web-сервисы к прикладной системе и имеем SOA. Это не так. Сервисы должны отвечать набору требований - как минимум  иметь бизнес-описание и достойную производительность. Есть тенденция обернуть API системы в web-сервисы, но обычно API не имеет бизнес-описания - это невозможно "ни понять, ни продать".

По поводу производительности - тоже есть мнение что SOA это медленно. Часто этот миф заставляет бизнес-персонал при планировании дизайна системы делать интеграционные обмены в обход ESB по стандартным интерфейсам обмена (файлы). Однако по всем исследованиям SOA продукты добавляют 5 - 10 % замедления в скорость работы процессов, а ориентация на файлы вызовет проблемы при переходе на более высокие уровни SOA.  

Да забыл - обычно внедрение SOA делят на 3 шага:
1. Выделение сервисов работы с прикладной системой (Level 4 SIMM - Simple services)
2. Связь систем через шину сервисов (Level 5 SIMM Composite services)
3. Построение Сервера бизнес-процессов (Level 7 SIMM Dynamically reconfigurable services)

Еще миф - что SOA требует покупки исключительно продуктов компании A, B,C. Это не так. SOA является архитектурным шаблоном и можно построения 1,2 шагов SOA на базе обычных J2EE серверов без необходимости внедрения промышленных ESB продуктов.

По сути SOA приносит ROI уже на ранних стадиях 1,2 шагов внедрения за счет ухода от "зоопарка" протоколов и централизации ИТ обмена. Целесообразно идти небольшими итерациями консалтинг - проект, которые стоит объединить в глобальный SOA Roadmap.

На ранних стадиях SOA проекты не принесут видимой отдачи и их надо связывать с конкретной новой задачей (внедрение новой системы). На поздних стадиях SOA проекты будут приносить очевидную отдачу.

Comments

( 4 comments — Leave a comment )
kaplin_pavel
May. 30th, 2010 07:44 am (UTC)
интересно, спс
вопрос, правда, возник, это подражание Платону по жанру? или это кусок интервью/фака?))
tri_botinka
May. 30th, 2010 08:17 am (UTC)
Это огрызки, полуфабрикаты, мысли - побочный продукт основной деятельности. Не имеющие конкретного обрамления, но так же мне дороги, которые было бы жаль потерять. Вот и выложил.
А жанр вопрос-ответ мне нравится. Не люблю читать в журналах огромные монологи. "Интервью" куда информативнее - и читать можно с любого места :-)
kaplin_pavel
May. 30th, 2010 12:56 pm (UTC)
все равно зачОтно)
gostwicky
Jun. 24th, 2014 09:48 am (UTC)
Высокоуровневая технология разработки в SOA
<<<В написании бизнес-сервисов принимают участие уже не один - а 5 специалистов разной компетенции - главный аналитик по продукту, бизнес-аналитик, системный аналитик, системный архитектор, проектировщик (если будет интересно - расскажу отдельно про "высокоуровневую" технологию разработки в SOA)>>>

Да, очень интересно, расскажите!
( 4 comments — Leave a comment )