Облом, или как провалился любимый ИТ-проект

«Его пример другим наука»
Это грустная история о неуспехе проекта, который я считал потенциально успешным на все 100 процентов. И почему все кончилось обломом, я до сих пор толком не понимаю.
За свою жизнь айтишника я участвовал в разработке многих успешных проектов. Большинство из них были сравнительно простыми по идее и посредственными по реализации. Справедливости ради, упомяну об исключении — выдающемся, на мой взгляд, проекте. Он был совершенно неординарным по замыслу (замысел был со стороны высокопоставленного банковского экономиста) и хороший по реализации. Реализовали его мы на ассемблере. Базой данных служили файлы прямого и последовательного доступа. Проект успешно эксплуатировался.
Однажды, участвуя в очередной посредственной разработке операционного дня банка, я столкнулся с необходимостью вычисления некоторых показателей, значения которых регламентировалось национальным банком. Это уже выходило за рамки дебета и кредита бухгалтерского учета. А я к этому времени прочитал книги «Экономикс»(автор Кэмпбелл и др.) и «Деньги»(автор Долан), и приступил к книге «Микроэкономика»(автора не помню, но зарубежный). Все это и послужило рождению идеи аналитики, как некоего аналога медицинской аналитики. Должны быть определены все показатели, достаточно полно отображающие состояние бизнеса. Это значит должны быть заданы точные правила вычисления показателей и реализован механизм их вычисления и использования. В идеале так и виделись работники с экранами, на которых отображалось текущее и прогнозное состояние дел, за которые отвечает работник. А работник задает вопросы типа:

  • А почему такой скачок у такого-то показателя?
  • А кто совершил такую-то операцию?
  • А что будет с состоянием, если совершить такую-то операцию?
  • А что будет с состоянием, если изменить такие-то показатели на такие-то значения?


И т.д.
И работник на основании всего этого принимает решения. Неужели кто-то откажется от таких перспектив? Ведь это настоящее современное рабочее место для творческого экономиста и менеджера.
В конце концов проект был реализован. И я наивно думал, что пройдет он на ура. Ведь кончилось время директивного управления, и значит нужен механизм, позволяющий держать руку на пульсе бизнеса (Я даже думал дать проекту название Бизнес-Пульс). А что случилось, увидим далее.
Я влюбился в проект и был в спокойной уверенности в его успехе. Но, увы … Надеюсь, что, хотя-бы для начинающих разработчиков, иcтория будет полезной.
«Скоро сказка сказывается, да не скоро дело делается»
Все названия фирм и банков не настоящие.

Фирма М. Начало


В М я участвовал в проекте валютного операционного дня банка (ОДБ). И тут я столкнулся с началами аналитики. Пришли нормативные документы, в которых определялись разнообразные нормативы деятельности коммерческого банка и регламент их применения. Нормативы определяли рамки риска для деятельности банка. И тут у меня, вдохновленного переводными книгами по экономике (упаси боже, было читать советские книги по экономике), забрезжила идея Аналитики — проекта, позволяющего пользователю определять и рассчитывать любые экономические показатели и контролировать их на соблюдение нормативных или других ограничений. Я поговорил с руководителями (а это были три дамы: президент, председатель, директор!!!), но не убедил их в нужности самостоятельного проекта. И я фактически оказался не у дел и мне стало и скучно и грустно. Но тут мне предложили подработать на стороне — разработать проект мультивалютного операционного дня банка (ОДБ) для фирмы НП. Я стал работать и в конце концов перешел в НП на постоянную основу разрабатывать проект мультивалютного ОДБ. Но задумка аналитики осталась в душе.

Фирма НП. Скромное продолжение


Итак, в НП я разрабатываю мультивалютный ОДБ. Помня о нормативах, упомянутых в предыдущем пункте, я их реализовал и подцепил к справке, которая выдавала определение показателя, формулу его вычисления и текущее значение. Все это было реализовано в лоб без всякой унификации и глубокой системы. Вот в Москве проходит очередная выставка банковских продуктов. И мы выставляемся. Подходит к нам одна банкирша и начинает знакомиться с нашим продуктом. Скоро звучит вопрос: «А как у вас дела с нормативами?». Я ей показываю таблицу текущих значений нормативов, она нажимает F1 и тут появляется определение норматива и формула его вычисления. Она была безмерно приятно удивлена, заявив, что ни у кого похожего не видела. И тут я укрепился в идее об аналитике. Если уж решение в лоб для нескольких показателей приятно удивило клиента, то что будет, если ему дать настоящую продвинутую бизнес-аналитику. В общем, я еще более воодушевился.

Банк БСБ. Личное систематическое начало


Как-то я демонстрировал в банке БСБ свой проект валютного операционного дня. Автоматизацией в БСБ ведал мой бывший шеф из банка ПСБ. Он посмотрел проект, попил со мною пару раз кофе и пригласил на работу к себе. А мы уже внедряли проект в одном из банков. А я, увы, внедрять был не очень охоч. И я согласился на переход. И вот я в БСБ. С работой справлялся быстро и было много свободного времени. Начал осваивать Delphi. Ознакомился с эксплуатируемыми задачами в банке. Оказался целый конгломерат разнотипных задач. Каждая автономна и со своим подходом. Я еще раз понял, что нужна единая банковская аналитика. Работаю над ней по собственной инициативе. Набросал концепции и начала техпроекта и обращаюсь с задумкой к шефу. Но как раз шеф набирает кадры из вычислительного центра ПСБ и они показывают некие зачатки банковской аналитики, которой они пользовались в ПСБ. Все реализовано на Oracle Discovery. А шеф сам выходец из ПСБ и айтишники из ПСБ и все они знакомы. И шеф решил пользоваться тем, что принесут ребята из ПСБ и не рисковать новыми подходами. Итак, меня прокатили. Но я продолжаю разрабатывать проект самостоятельно. Времени хватало. Я самообразовываюсь — читаю толстые книги: «Управление финансами в коммерческих банках»(автор Синки), «Банковский менеджмент»(автор Роуз), «Финансовое управление фирмой»(автор Смит и др.). И еще больше укрепляюсь в своей идее.
Когда я уже ушел из БСБ, то узнал, что БСБ склоняется к мысле приобрести SAP, что в итоге и сделали. Потом несколько лет внедряли, и я уже не знаю внедрили ли. Да, было модно обращаться к западным продуктам. Объяснение простое: ведь это означало систематические зарубежные командировки за счет банка.
Меня продолжает вередить зуд аналитики. И вот я решил продвинуть ее на частном примере кредитования. Кратко о сути задачи. Есть портфель кредитных заявок. В общем случае весь портфель удовлетворить нельзя: может не хватить обеспечивающих ресурсов. Плюс ко всему есть набор нормативов, которым должно удовлетворять состояние банка. Значит есть проблемы выбора. А где есть несколько вариантов выбора, там возникает задача оптимального выбора. Критерий оптимизации может быть разным, например:

  • Интегральная процентная прибыль за некоторый период
  • Чистая приведенная стоимость выбора за тот же период


Дело осложняется тем, что каждый клиент характеризуется некоторым риском. Значит критерий должен взвешиваться по вероятности возврата кредита. Мне удалось свести задачу к задаче линейного программирования. Риск по клиенту задавался моделью эмпирического риска, которую пришлось разработать самому. Сложность представляли нормативные ограничения, которые задавались нелинейными формулами. Оказались, что они только по форме нелинейные и тождественными простыми преобразованиями их можно свести к линейным. Риск можно было задавать и априорно.
Итак, постановка сделана. Нужно получить в банке одобрение проекта. Иду к руководству. Руководство не может само оценить предложенные идеи и меня посылают в какой-то полунаучный отдел (забыл точное название) и я попадаю на консультацию к кандидату экономических наук, бывшему нархозовцу (институт народного хозяйства). Не знаю почему, но тот сразу ополчился против и понеслись фразы типа «i, j все писать умеют». В подтексте слышится: «Пришли тут неостепененные» и »… Суди дружок не выше сапога». И никак ему не втолковать, что проект не претендует на науку, а предлагает конкретную разработку и алгоритм под неё, так что можно приступать к программированию. Но это никак не втолковать. В итоге никаких рекомендаций я не получил. «Ну и фиг с вами. Пусть все будет как есть». Это был второй раз, когда я встретился с отраслевой наукой и второй раз я попал к ней на рога.

Фирма МРЦ. Личное систематическое продолжение


Шеф уходит возглавлять МРЦ. Он забирает меня с собой. Фирма денежная и может финансировать несколько проектов. Я начинаю зондировать разработку проекта бизнес-аналитики. Продолжаю делать наброски технического проекта. Разрабатываю средствами CASE структуру БД. И тут мне опять представился случай проявить инициативу. Полным ходом идет разработка системы RTGS (Real Time Gross Settlement) — реализации в реальном времени крупных платежей. Проект курируется Европой. Регулярно приезжают холеные европейские консультанты, которых мы угощаем растворимым кофе из нехоленых ржавых банок. Регулярно в Европу ездит наше руководство. Обслуживает руководство переводчики из моего управления. И у меня в управлении стоит целый книжный шкаф ценных переводов по банковской проблематике. Большинство из них я не могу уразуметь, то ли из-за сложности тематики, то ли из-за качества перевода. Ну хорошо, разрабатывается RTGS. А что делать с мелкими платежами? Предполагается, что они будут реализовываться в режиме клиринга. На клиринг нет ни постановки, ни вразумительной терминологии. И вот я берусь самостоятельно разрабатывать проект Клиринг. Разрабатываю словарь терминов и приступаю к техническому проекту. Словарь даю на обозрение широкой публике. Энтузиазм из меня так и прет.
Но тут наступают новые политические времена. Арестовывают Винникову, председателя Нацбанка РБ. А мой шеф возглавил МРЦ по представлению Винниковой. И вот началось выдавливание всех, кто прямо или косвенно был связан с Винниковой. Шеф увольняется. И меня начинают прессовать. Даже сослали в дальнюю от моего управления маленькую комнатку. Приходит новый начальник. Я ему несу на рассмотрение свой проект клиринга. Начальник держит проект у себя около месяца. Я ждал, ждал и обращаюсь к нему. А в ответ услышал: «Разработка проекта не входит в Ваши прямые должностные обязанности». Вот вам и инициатива. Я прошу вернуть проект. Начальник мнется, мнется, но все-таки возвращает проект мне и проект до сих пор пылится у меня на балконе. Да, кстати, по теме клиринга я написал в отраслевой журнал статью. В ней предлагалась модель, определяющая временной лаг клиринга, оптимизирующий использование ресурсов клиринга. Статью приняли и напечатали без всяких препонов. Воодушевленный я развил идею дальше и понес в журнал вторую статью. И тут по поведению редактора я понял, что канал перекрыт. И мне стало ясно, что пора сваливать самому, не ожидая пока попросят. Обращаюсь к фирме СК и предлагаю проект аналитики. Тут же получаю приглашение на работу. Значит, я на правильном пути.

Фирма СК. Начало венчурного финансирования


Итак, я в СК и руководитель проекта Zero. Это проект банковской аналитики. Кроме руководителя пока нет никого. Пока один. Начинаю реализацию на Дельфи. Проходит месяца три и меня вызывает технический директор и просит ознакомить его с состоянием проекта. Знакомлю. Уже кое-что есть. А директор говорит: «А почему бы не перейти на самоокупаемость — продавать проект по частям, которые уже реализованы?» Я опешил. Начинаю возражать, что мол МАЗ не продает колеса, а продает самосвалы. Попикировались и разошлись.
Начинаю чувствовать пристальное внимание со стороны главного инженера. Это был мой непосредственный начальник. Вся проектная идеология исходила от него. Человек талантливый и с жесткими взглядами на управление и с мягкими пряниками похвалы. Он все время зондирует мои дела и однажды объяснился. Он разработал интерпретатор подмножества Паскаля и все банковские отчеты главного продукта фирмы делались на скриптах этого интерпретатора. Скрипты назывались ОПР, не помню почему. Так вот, сказал он проект нужно делать на ОПР и вся аналитика должна сводиться к отчетам, написанными на ОПР. Это был еще не приказ (а он, конечно, имел право приказать). Мы начали дискутировать. Я как плюсы своего подхода приводил объектный подход и гораздо более систематический подход к показателям вплоть до их кодирования и подход к аналитике не как к отчетам, а как к моделированию экономических ситуаций и анализу последствий моделирования. В общем была приятная нормальная дискуссия. Такие дискуссии продолжались несколько раз. Это хорошо, это правильно. Но, однако, ни он ни я не меняем свою точку зрения. Тогда босс предлагает организовать публичный диспут, в котором каждая из сторон представит свой список аргументов. Отлично. Но в день дискуссии я узнаю, что босс вмещался в мой список и скорректировал его на свой вкус с позиции начальства и представил исправленный список публике. Это меня шокировало. Ведь ты как начальник мог приказать мне работать так как ты считаешь нужным и я, или должен принять это, или уволиться. Но если свободная дискуссия, то не затыкай мне рот. Мы на равных. В общем диспут я проиграл, хоть и не с разгромным счетом. «Бодался теленок с дубом». Я получил хороший урок корпоративной этики и стал искать новую фирму. И нашел — АТЛ.

Фирма АТЛ. Конец венчурного финансирования


И тут, наконец, я получаю карт-бланш для любых фаз разработки. И разрешение на набор команды. Но когда я еще один работал, босс уже пригласил потенциальных клиентов на просмотр продукта. И вот банкир из Казахстана изъявляет желание приобрести проект. Хорошо, что босс спросил у меня готов ли я. Я отказался от внедрения: cамому разрабатывать и самому внедрять — не слишком ли. И я стал набирать команду. Больше 8 человек в бригаде никогда не было. Каждому человеку давался приличный самостоятельный кусок проекта. Я составлял на него ТЗ и вперед. Через месяц, два становилось очевидным годится ли человек.
Итак, проект стал развиваться быстрыми темпами. Некоторые функции подсказывали потенциальные клиенты. Например, я демонстрирую проект французам. Дошел до графиков динамических рядов. И тут один француз спрашивает: «А вы не скажете, почему в прибыли тут такой скачок?». И тут же мелькает мысль: «Как это я, дурак, сам не додумался задать себе такой вопрос?». В результате появилась операционная декомпозиция — набор всех операций, изменяющих заданный показатель в заданное время. А с операции можно выйти и на ее исполнителя.
Хранение и обработка динамических рядов, сценарное моделирование, виртуальные показатели, статистическая проверка гипотез, регрессии, поиск наилучших регрессий, обработка портфеля финансовых инструментов, разного рода декомпозиции значений показателей, разного рода компараторы — все реализовывалось на мой взгляд быстро. Проект становился все солиднее. Я попробовал ради интереса реализовать Web-интерфейсы для создания Web-служб. Это оказалось несложным, но далее web-тематику мы не развивали.
Начали выставляться на ИТ-выставках. Я демонстрировал не презентацию, а реальную работу продукта. Позже я от этого отказался, так как это слишком большой стресс. У меня даже руки стали дрожать, когда нужно было реально продемонстрировать требуемое свойство. Интерес к продукту был и немаленький. Из одного солидного банка пришло ИТ-руководство. На следующий день пришла целая бригада из ИТ-департамента. Потом пришла бригада банкиров. А мне все показывай им. Ну думаю, дело на мази. Увы. А в большинстве приходили ИТ-шники. И до того дотошно расспрашивали, что однажды я прямо спросил: «Так вы намереваетесь брать или просто так интересуетесь?» А в ответ: «Да нет, брать мы не будем, мы просто тоже делаем что-то подобное и поэтому интересуемся как дела у других». Я взял и напросился посмотреть их проект. Не отказали. Проект был реализован на java. Он имел дело только с генерацией показателей. И эта генерация занимала на мой взгляд слишком много времени. И, поэтому, генерация шла в ночное время.
Однажды прекрасным весенним выходным днем меня вызывают на работу. Нужно показать проект важному банкиру из Питера. Проект банкиру очень понравился и он попросил приехать в Питер и показать проект широкой публике. Едем. Присутствует весь менеджмент банка. Нас представили и тут до представления начались бурные дискуссии между менеджерами. Одна партия за существующий там проект, а вторая за нас. Мы слушали, слушали и попросили прервать дебаты. Мол, мы покажем проект, а потом дебатируйте. Так и сделали. В итоге решили, что мы переведем всю БД нашего проекта на питерский Progress, сохранив то, что уже есть в нем и дополнительно в рамках нашего проекта реализуем несколько новых функций. Потом все это мы покажем и далее решится судьба проекта. Мы реализовали то, что требуется и собираемся в командировку в Питер. И вот пришло время ехать. И тут шеф дает отбой. Что и почему, я так и не узнал, так как не был посвящен в бизнес-интриги. И Питер обломился.
Были посетители и из Парижа. Глава делегации был какой-то потомок русских эмигрантов. Русский он знал неплохо. Судя по всему, проект ему понравился и он в знак уважения (?) подарил мне ноутбук от IBM., правда не совсем последней модели. Ноутбук и сейчас работает. Вскоре шеф приказывает мне готовить проект для Парижа. Вот это да! Перевели на французский всю документацию. Локализовали проект. Обмениваемся данными с банком в Париже. Готовимся к командировке. И тут шеф говорит, что наш покровитель переходит на повышение в другую фирму, не связанную с нашей тематикой… И все затихло.
Мой бывший шеф по МРЦ возглавил в банке ПСБ департамент стратегических исследований. И он разрешил мне поставить проект на апробацию. И что я вам скажу? — Никогда не пробуйте эксплуатировать у заказчика сырой проект. Только навредите репутации. Так и случилось. После пары сбоев — прохлада со стороны банкиров. Да и вид у всех типа » Кому нужно дополнительная работа без дополнительной оплаты». В конце концов мой знакомый при очередной встрече за рюмкой и обсуждению текущего политического момента произнес сакраментальную фразу «При такой политике не нужно аналитики».

Векселя


И тут представилась возможность реализовать маленькое подмножество аналитики на примере обработки векселей. Работа с субъектами полностью была взята из аналитики. Ну, и несколько показателей пригодились также. Быстро реализуем проект Векселя. Проект внедрен. Идет сопровождение. И тут грянул гром. В контрольные органы поступила кляуза, что на проекте отмыты деньги, а проект не делает то что нужно (Похоже дело было в том, что у нас работал сын заказчика проекта Векселя). И вот мы разработчики должны продемонстрировать проект ревизору. Хорошо, что мы детально изложили ТЗ и четко реализовали все пункты ТЗ в проекте. Продемонстрировали ревизору работу проекта по всем пунктам ТЗ. Придраться было не к чему. А проект стоил мизерные деньги и как на нем можно было нажиться не представляю. По крайней мере мы на нем не нажились.
Проект был спасен и мы уже подумывали о его развитии. Но тут президент запретил вексельную форму расчетов. И хотя нас просили сохранить всю инфраструктуру проекта (работа с субъектами хозяйствования…), но о деньгах речь не шла и нам не было резона трудиться.

Поиск криминала


А тут подвернулся еще один проект, который можно и нужно было связать с аналитикой. Объявился интересный потенциальный заказчик. Он описывает нам предмет автоматизации примерно так. Есть множество субъектов и множество отношений между ними. Нужно определить прямые и производные атрибуты, которые характеризуют степень финансовой криминальности субъекта и на основании атрибутов криминальности выявлять подозрительных субъектов и отслеживать их. Предполагаемый заказчик говорил только, что нужно вести досье и дело на каждого клиента, а также собирать сведения о всех отношениях субъекта. Основные поставщики данных: МВД, банки, налоговые органы, собес, таможня, интерпол…
Начались дебаты разрабатывать ли самим или брать покупной продукт. Заказчик склонялся к покупному варианту. Оно и понятно: зарубежные командировки, красивая реклама продуктов (сами продукты не имели демоверсий и их нельзя было реально пощупать), а деньги бюджетные, чего их считать. Я начал разрабатывать ТЗ. Скоро понял, что вряд ли оно будет завершено. Дело в том, что мой новый шеф пытался добиться того чтобы все документы, структуры, файлы были определены на стадии ТЗ. Фактически он хотел втиснуть в ТЗ техпроект. Вдобавок, каждое решение должно было протоколироваться за подписью заказчика и разработчика. Поэтому по каждому пункту ТЗ собирались совещания с заказчиком. Я высказал свои сомнения в успехе подобного подхода и стал параллельно по собственной инициативе разрабатывать самостоятельный проект на Дельфи. Мне было просто интересно. Основная информационная структура — ориентированный нагруженный граф отношений. Узлы графа — субъекты, ребра графа — отношения, нагруженные типом, размером, датой начала отношений, датой активации отношения… В графе могут быть различные поиски: цепочки однородных отношений, цепочки неоднородных отношений, цепочки заданной длины, циклы, цепочки отношений, с размерами превышающими заданный лимит и т.д. и т.п. Разработал соответствующие классы и сравнительно быстро реализовал проект. Я продемонстрировал его руководителю предполагаемого проекта поиска криминала. На нескольких десятках тысяч субъектов, сотен тысяч отношений, десятка полтора типов отношений, любая цепочка находилась примерно за секунду. А буквально на следующий день руководитель сказал, что заказчик прекратил с нами отношения. Как и следовало ожидать, дальше ТЗ дело не пошло. А прошло около года. Мораль: не нужно слишком взнуздывать заказчика. А может шеф и не хотел этого проекта. Дело в том, что он был ответственен и за проект ERP для КГБ, а проект горел…
А я, работая с отношениями, заинтересовался языком Prolog, точнее Visual Prolog. Начал пробовать. И удивительно, если в Дельфи реализация поиска цепочек требовала немалых усилий и размера программ, в Прологе это делалось компактной декларацией. Вот что значит заточенность языка на проблему и его декларативность. Описание предметной области декларативно и поэтому оно сравнительно легко ложилось в декларации Пролога.
Но не очень понравились возможности Visual Prolog по выводу форм. И у меня забрезжила мысль, что каждой специфичной проблеме нужен свой язык. Язык проектирования и генерации отчетов, язык проектирования ввода данных, язык проектирования вывода данных, язык коммуникаций, язык обработки отношений, язык обработки списков, язык описания данных, язык бизнес-аналитики, язык размещения сервисов и управления ими, язык бухучета, … Короче, нужны не универсальные, а предметно-ориентированные языки. Дело только в стандартизации интерфейсов между получаемыми модулями. Зачем мне вся мощь C# с Visual Studio, если я, например, разрабатываю только формы, или только отчеты, или только обмен с БД, …
Проект был включен в аналитику в подсистему Отношения.

Отступление о технических писателях


Когда я стал работать с вышеозначенным руководителем (он также бывший физик), тот стал жаловаться, что никто из его молодых подчиненных не в состоянии толком написать документацию. Я вполне с ним согласился и всю документацию по своим проектам писал сам. Вплоть до презентаций на Powerpoint.
Теперь мне кажется, что проблема технического писательства еще более обострилась. Люди стали мало читать, а пишут только интернет-комментарии, которые иногда стыдно читать.
Какой язык самый главный? — твой родной. Его нужно знать в первую очередь.

Попытка интеграции


Проектом интересуются, но проект не покупается. Я заволновался и стал искать причины. А в то время главным банковским ИТ-продуктом на рынке был операционный день банка (ОДБ). И я решаю расширить рамки проекта и сделать интегрированный проект, включающий в себя: ОДБ, кадры, депозиты, кредиты, натуральный учет, операционный учет. Шефа долго не пришлось уговаривать. С ОДБ дела пошли удовлетворительно. А вот с кредитами и депозитами получился конфуз. Дело в том, что кадры на эти проекты мне не пришлось набирать самому, а пришлось ограничиться людьми из одного перспективного, но неудавшегося проекта. Ребята молодые, бойкие, склонные к системному программированию. Так и слышно: сокеты, TCP/IP, Internet, паттерны… Проходит месяц а, а прогресса никакого. Но каждое утро ребята бурно обсуждают «Формула-1». Так и слышится » А Шумахер то, а Алонсо то…». После обсуждения формулы-1 переключались на алгоритм деления трафика интернета между сотрудниками. Да, был такой социалистический реликт справедливого дележа трафика между сотрудниками. Дело кончилось тем, что я предложил депозитникам и кредитникам уволиться. Что и произошло.
А тут начались новые времена. Фирмой владел и руководил приятный бизнесмен. Очень религиозный человек. И в фирме была толстая прослойка из его единоверцев. И все шло более-менее спокойно. А тут вдруг, я не знаю почему, появляется новый руководитель — свежеиспеченный пенсионер КГБ высокого чина. Скоро мы получаем заказ на проектирование ERP для КГБ. С течением времени проект стал заваливаться и требовалось срочно укреплять группу разработки ERP. А мой проект был венчурным и работали в нем неплохие ребята. И вот начали выдергивать из моего проекта людей. И возразить нельзя: ведь мы сидим на шее других проектов. Так я вскоре опять остался один. А в фирме все росла прослойка КГБ. Начался проект по разработке аппаратуры шифрации-дешифрации.

Финал


В конце-концов, я остался один на проекте Аналитика. Подбросили сторонний заказ для управления МВД — доработать ASP-проект. Доработал. И тут оказывается, что фирма банкротится. Это, кажется, был хитрый бизнес-ход: параллельно с процессом банкротизации возникла новая фирма с людьми из нашей банкротящейся фирмы и которые были целиком завязаны на КГБ- разработку криптографической аппаратуры. А старая фирма обанкротилась. И моя аналитика стала домашним проектом. Но по инерции интерес к проекту еще некоторое время не угасал. Пришла пора .Net. Я понял, что уже сравнительно легко перейти к SOA-архитектуре. Перевел почти всю бизнес-логику с Delphi на C#. Познакомился с WCF. Выделил сервисы. Определил интерфейсы. Реализовал шлюзы сервис-клиент. И вот она SOA-архитектура. Была задумка реализовать простую оркестровку сервисов, но, кажется, в этом уже нет необходимости. Эта функция стала системной.
Однажды звонит телефон. Звонили айтишники, которые задумали разработать бизнес-аналитику. Они обратились к владельцу портала tut.by у которого я когда-то разработал проект валютного ОДБ. Мой бывший шеф (царство ему небесное) всегда подходил ко мне на выставках и я ему рассказывал о своих успехах. Он высказал несколько дельных маркетинг-замечаний, которые заставили меня призадуматься. Так вот он направил ребят ко мне. Они рассказали о своих планах. Я им сказал, что их задумки уже давно реализованы, но положены на полку. И я им продемонстрировал проект. Они поняли, что это весьма трудоемкое дело и предложили выступить в роли толкателей моего проекта в банки. А я уже вступил в стадию пессимизма перспектив толкания в банки. Но ребята упросили меня попробовать. Я им — дерзайте. Снабдил их рекламными материалами, письмом в банки и они пошли толкать. Результат оказался предсказуемым.
Я до сих пор не могу определить причины неуспеха.
Я попробовал отдать проект в EPAM. Там резонно ответили, что разрабатывают только под заказ, а венчурными разработками не занимаются. Есть у нас в Минске Парк Высоких Технологий — ПВТ, работающий под покровительством президента республики. И в нем есть отделение Бизнес-инкубатор. Я послал туда предложение передать бесплатно им свой проект. Никакого ответа не последовало. Я посмотрел в интернете что такое инкубатор и нашел вот что. «инкубатор (от лат. incubare, здесь — высиживаю птенцов) — аппарат для искусственного вывода молодняка сельскохозяйственной птицы из яиц». Он дает жирных, но неприспособленных для неинкубаторской, реальной жизни особей. Похоже на правду.
«Не все золото, что блестит»
А теперь более детально о многострадальном проекте. Это чтобы было оценить обоснованы ли были мои ожидания и стоит ли о них переживать. Это не реклама проекта. Проект мертв. Я готов бесплатно отдать его в хорошие руки. Если кого-то заинтересуют некоторые детали проекта, то смотрите. Старый первоначальный вариант описания (поэтому возможно более интересный) вот здесь.

Принципы


  • SOA
    Под сервисом понимается автономное приложение коллективного пользования, функции которого предоставляются через анонсированный разработчиком API. Сервис можно размещать на любом компьютере сети. В архитектуре клиент-сервер сервис был один — СУБД. В SOA сервисов может быть сколько угодно и размещаться они могут на разных компьютерах сети.
  • WCF связь клиент-сервис и сервис-сервис.
  • СУБД
    В БД никаких хранимых бизнес-процедур. СУБД достаточно загружена стандартными запросами сохранения, обновления и извлечения данных. Отсутствие хранимых бизнес-процедур сильно облегчает смену СУБД. Особенно если еще стараться ограничиваться стандартом SQL.
    А если обнаружится, что сервер БД слабо загружен, то на нем можно разместить сервис работы с показателями, например.
  • Отчеты
    В отчетах не должно быть никаких бизнес-функций. Отчет — просто отображение группы показателей в заданную форму. А сами показатели должны рассчитываться в бизнес-слое сервисом машины показателей.
  • Интерфейсы
    Любое обращение к сервису должно быть только через интерфейсы.
  • Группы
    Однотипные объекты (показатели, субъекты, операции…) могут объединяться по любому допустимому логическому критерию. Групп может быть сколько угодно.
  • Эксплореры
    Иерархические структуры должны отображаться в едином эксплорере

Основные функции


  • Ведение субъектов и их отношений. Поиск по отношениям. Ведение групп субъектов.
  • Ведение показателей и их динамических рядов. Ведение групп показателей. Значения показателей могут быть числовыми, текстовыми, логическими, календарными. Правило вычисления показателя — любая композиция стандартных математических функций и агрегатных функций. Примеры агрегатных функций: максимум по субъектам, среднее по времени, минимум по времени…. Значения показателя представляются в нескольких измерениях реальности: факт, план, прогноз индивидуальный, прогноз статистический, прогноз сценарный. Удивительно, но нигде в литературе я не нашел систематизированного перечня бизнес-показателей с их определениями, кодами, наименованиями и правилами вычисления.
  • Статистический анализ динамических рядов. Проверка статистических гипотез. Нахождение статистических параметров.
  • Регрессионный анализ. Нахождение наилучших регрессий.
  • Ведение портфеля. Получение платежного календаря.
  • Прогнозирование. Прогнозирование линейными трендами. Прогнозирование по портфелю фининструментов. Прогнозирование с учетом статистического отклонения прогноза от реальности.
  • Сценарное моделирование. Различные типы сценариев: операционный, портфельный, индикаторный.
  • Анализ. Различного рода анализаторы (декомпозиторы): разложение по показателям, по субъектам, по валюте, по исполнителям, по операциям.
  • Сравнения. Различного рода компараторы: сравнение по времени, по субъектам, по показателям.
  • Отображение в реальном времени. На каждого пользователя заводится табло своего типа, в котором отображается группа показателей.
  • Ведение плана счетов, иерархии объектов учета, иерархии бизнес-операций и их отображения на проводки.
  • Элементы бюджетирования: игра с распределением ресурсов.

Основные технологии


  • ETL. Это неунифицированный модуль перекачки данных от подсистем источников первичной информации. Основной источник — бухгалтерский учет.
  • Эксплорер как универсальное отображение иерархических структур. Унифицированно отображаются иерархии показателей, субъектов, отчетов, запросов, объектов учета, операции.
  • Группы как наборы объектов, объединенные некоей общей внешней семантикой. Например, отчет — группа показателей, отображаемая по заданной форме.
  • События. Монитор событий отслеживает рождение событий. Событие специфицируется логической функцией. Типы событий: внутреннее бизнес-событие, внешнее бизнес-событие, календарное событие. Монитор — общий для всех сервисов. В каждом адресном пространстве работает свой оповещатель событий. Он извещается монитором событий. На события приложение подписывается.
  • Динамические формы. Пользователь может конструировать экранные формы таких типов: списочные, матричные (=табличные), иерархические.
  • Элементы объектооборота.
  • Сервисы.

Функциональные сервисы


  • Бизнес-ядро. По запросу клиента предоставляет ему для использования бизнес-объект и забирает объект от клиента. Кэширует объекты. Управляет связью между бизнес-уровнем и уровнем хранения д

    © Habrahabr.ru