Максимов И.В.
МУ ЦМИРиТ


МУ ЦМИРиТ занимается разработкой ПО ИС для муниципалитетов уже довольно давно, с 1998 года. Принимал участие во многих конференциях посвященных этой тематике, сотрудники МУ ЦМИРиТ сами неоднократно проводили семинары и конференции по этому вопросу.

Ниже представлены проблемы, с которыми МУ ЦМИРиТ столкнулся при внедрении МГИС на территории Вологодской области и не только в ней. Те же проблемы наверняка существуют в других регионах. Их можно разделить на две группы или типа функциональные и системные. С одной стороны проблемы связанные с эксплуатацией и развитием ИС у клиента с точки зрения изменения бизнес функций реализуемых ИС в зависимости от сложившейся ситуации, изменений в законодательстве, обслуживания технических средств и т.д. Это функциональные проблемы. С другой стороны проблемы связанные развитием ИС с точки зрения ИТ. Это повторное использование кода, преемственность поколений программистов то что можно был бы охарактеризовать фразой: "Не надо ломать все, что было до вас! Надо развивать то, что уже есть!" Это системные проблемы.

Вот не полный перечень проблем, которые могут быть отнесены к типу функциональных.

1. Отсутствие технических специалистов обслуживающих ИС и необходимых для создания полноценной ИТ инфраструктуры. Это относится к специалистам в области администрирования БД, Операционных систем, сетевой инфраструктуры.

2. Отсутствие специалистов способных изменять ИС в соответствии с изменившимися условиями ведения бизнеса. Поменялось законодательство, поменялись алгоритмы и т.д. Способных дорабатывать ИС выполняя функциональные ООА и ООП.

3. Отсутствие должного финансирования для создания полноценной, современной ИТ инфраструктуры. Это касается не только приобретения "железа", но и ПО, часто весьма дорогостоящего, и самое главное, его технической поддержки.

4. Высокая текучесть кадров, операторов прикладных подсистем, и как следствие, появление субъективных требований к системам в зависимости от мироощущения и понимания задач конкретным оператором. Зачастую такой оператор имеет опыт работы с другими продуктами выполняющими те же функции но по другому. Это можно охарактеризовать фразой "Мне не удобно".

5. Отсутствие аналитиков, способных сформулировать функции предметной области с точки зрения законов применяемых в этих областях. Например, если речь о биллинговых системах или системах оценки стоимости оказанных услуг, расчета и списания денежных средств в соответствии с действующими тарифами, то должны использоваться в том числе правила и принципы бухгалтерского учета. Классическими биллинговыми системами являются разного рода "Аренды".

6. Еще одна проблема это боязнь руководителей размещения "своих" данных на "чужих" ресурсах. Но зачастую "чужие" ресурсы доступнее "своих". Примером могут служить новостные или погодные сайты в интернете или тот же проект Google Earth. Где снят весь земной шар.

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

Вот пример автотранспортных предприятий. Они имеют парк машин и гарантируют перевозки беря на себя проблемы подготовки водителей и ТО автомобилей. При этом они гарантируют доставку груза из пункта А в пункт Б. Заказчик всего лишь пользуется их услугами.

С другой стороны есть проблемы связанные собственно с развитием ИС как таковых. Их можно отнести к системным проблемам. Это означает, что даже если есть специалисты в области ИТ у потребителя, то они сталкиваются со следующими проблемами:

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

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

3. Процесс управления проектированием, реализацией и эксплуатацией ИТ проектов.

4. Амбициозность ИТ-служб на местах, или отдельных программистов и прикладных операторов, зачастую мешающая внедрению ИС. Их действия могут приводить к "тихому саботажу", поскольку они боятся, что их уволят, или что вместо них будет работать "программа". Программисты напротив стремяться повысить свой уровень за счет программирования как такового, у них нет цели совпадающей с бизнес целью компании. Однако существует объективная, замена ИС обуславливается предыдущим, тупиковым, развитием системы приводящему, в плоть до полной ее остановке. Также замена ИС может быть связана с уходом "главного программиста". В практике Максимова Игоря Витальевича были и такие случаи.

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

Одним из вариантов решения вышеназванных проблем может быть организация сети дата-центров, причем, базирующихся на уже существующих организациях, пример, таких как МУ ЦМИРИТ г. Череповец, аналогичные центры в Волгограде, Томске, Уфе, Нижнекамске, Омске и других городах.

Предлагаемая идея не содержит ничего нового и революционного и состоит в том, чтобы обратиться к концепции дата-центров или "облаков". Можно выделить следующие основные функции дата-центра:

1. Обеспечение доступа потребителя к своим данным по схеме 24х7 с использованием VPN каналов интернет в любой удобной потребителю точке.

2. Обеспечение сохранности и конфиденциальности данных потребителя. Гарантия того, что данные принадлежащие потребителю будут выданы дата центром по его требованию незамедлительно. Данные хранящиеся в дата центре и принадлежащие потребителю могут быть уничтожены только самим потребителем.

3. Дата-центр обеспечивает техническую поддержку ИС потребителя с точки зрения доработки и сопровождения, но не в коем случае не диктует условия, по которым только конкретный дата-центр может менять и дорабатывать ИС потребителя. Важно что бы дата центр мог принять разработку потребителя выполненную самостоятельно или в результате аутсорсинговых мероприятий.

4. Электронный обмен между дата центрами метаданными и данными. Это позволит обмениваться наработками и знаниями, накапливаемыми в каждом дата-центре и как следствие качественее удовлетворять потребителей услуг.

5. Очень важно, чтобы имеющиеся у потребителя услуг дата центра ИТ специалисты изменяли и сопровождали ИС используя наработки поколений предыдущих специалистов используя общую понятную всем специалистам дата центра документацию.

Все что сказано выше по сути является теорией. Конкретная же скть предложения заключается в следующем.

Создается сеть дата центров, которые договариваются в обмене знаниями (подсистемами) на основе соблюдения взаимных интересов. Для реализации этого положения необходимо, что бы дата-центры участники имели общую архитектуру построения ИС. В качестве такой архитектуры можно предложить метаописание ИС Е3 и среду обмена знаниями Е3_to_E3. Среда обмена знаниями основана на P2P сетях. Каждый дата-центр обладает свом штатом специалистов в области ИТ. ИТ является основной бизнес функцией дата центра. Специалисты, отвечающие за развитее и создание ИС, соглашаются с использованием единой методологии разработки и сопровождения ИС в данном случае основанной на E3 и E3_to_E3 взаимодействии. При этом ни каким образом не ограничены в выборе БД, языков программирования или ОС. Каждый дата-центр отвечает только перед своими потребителями услуг за достоверность, непротиворечивость, доступность и т.д. данных.

Можно представить два типа полярных клиентов дата центров:

1. Дата центр, обслуживающий клиентов. у которых нет ИТ специалистов, например, администрация небольшого сельского поселения. Такое МО не может выполнять техническое обслуживание БД, сопровождать ПО и т.д. Эти функции возлагаются на дата центр и ответственностью клиента становиться только выполнение непосредственных функций в подсистемах. Например, ведение ИС ОГД или ведение договоров аренды земли. Их основная проблема это поиск того, кто решит их проблемы. Таких клиентов абсолютное большинство.

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

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

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

Если клиент принадлежит к первому типу, то со временем проходя сложный путь проб и ошибок, клиент вырастает в клиента второго типа. Этот путь может быть долгим, дорогим и сопровождаться большим количеством ошибок. Очень важно сократить его до оптимальной длины и приемлемого количества ошибок. Как это можно сделать? Вот суть предложений Игоря Витальевича:

1. Предложить архитектуру прикладных подсистем, описанную моделью с четко определенной семантикой это E3Core.

2. Предложить архитектуру обмена созданными своими знаниями с аналогичными центрами. Это E3_to_E3 обмен.

Какие цели при этом достигаются:

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

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

Эти две цели достигаются постулированием семантики формально и однозначно интерпретируемых моделей. Это очень похоже на стандартизацию (стандарты). Однако в отличие от стандарта, я предлагаю на ряду со спецификацией, конкретную реализацию в виде E3Core. К стати это развитие ECore, существующее уже порядка 10 лет и успешно эксплуатируемое в ряде центров. Маленькое отступление. Переход от ECore и win frame эля таких клиентов, простая формальность не требующая дополнительных затрат на обучение.

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