Enterprise Developer Conference

Пока в Интернет появился всего один отчет о прошедшей накануне Enterprise Developer Conference, а именно размышления Андрея Колесова. Выскажу свои соображения о прошедшем мероприятии. Вернее, не столько о мероприятии сколько, о затронутой теме: разработка ПО внутренними силами предприятия. О самой конференции еще наверняка напишут.

Итак, кто же все эти люди, разрабатывающие ПО, но не являющиеся сотрудниками ни Microsoft ни IBM, ни даже компаний системных интеграторов? Зачем Microsoft собрал их на эту встречу и чему хотел научить? В общем-то, большинство докладов было посвящено именно разработке. Организаторы честно запускали Visual Studio, создавали контролы и редактировали фрагменты кода. Вот только радости участникам конференции, на мой взгляд, это практически не доставляло. Среди гостей мне удалось распознать несколько знакомых ИТ-менеджеров, преподавателей ВУЗов, учебных центров и нескольких журналистов. Вряд ли они так уж часто открывают интегрированные среды разработки. Наверное, потому и не было особой радости на их лицах. Конечно, были и настоящие разработчики, но большинства они не составили. Вспомните «Волшебный котел» Эрика С. Реймонда утверждающего, что до 95% программного кода пишется вовсе не на продажу, а для собственных нужд. Может быть это время ушло(«Волшебный котел» написан в 1999г.) и компании полностью передали разработку ПО на аутсорс? Что-то я сомневаюсь. Скорее внутренние разработчики банков, страховых компаний и прочих предприятий просто не ожидали, что для них может быть организована специальная конференция и потому не пришли. В лучшем случае ограничились просмотром трансляции конференции в Интернет. Потому и тема собственной разработки так и осталась не раскрытой.

А упомянутые энтерпрайз девелоперы так и продолжа решать свои проблемы самостоятельно: Как убедить руководство в нецелесообразности приобретения очередного «промышленного решения», в каком объеме и нужно ли вообще платить за сопровождение платформ и заказных решений, где допустимые границы кастомизации решений.

Впрочем, начало разговора положено. Будем ждать продолжения.

Direct Graph Markup Language

Был вчера на конференции Enterprise developer conference. О конференции чуть позже, сначала про DGML.

Microsoft встроил в Visual Studio функционал построения графических моделей из проектных репозиториев, разработав попутно для этого XML-based язык описания ориентированных графов. Какие объекты использовать в качество узлов графа(сборки, неймспейсы или классы) решать архитектору. Думаю, без больших проблем можно использовать и другие объекты. Или же просто нарисовать такую картинку как эта

В общем-то, идея вполне симпатичная, тем более что GraphVis уже давно не развивается. Посмотрим насколько это новшество приживется в практической деятельности разработчиков

Case management и модели процессов

Продолжаем читать статью Хенка де Мана «Case Management: A Review of Modeling Approaches»

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

  • CM предполагает постоянный сбор информации относительно конкретного рассматриваемого случая. Данная информация существенно влияет на то, как мы обрабатываем кейс.
  • Кейс обладает набором состояний, которые управляются событиями (event-driven), как правило, событиями внешними.
  • Значительное влияние на порядок обработки кейса в CM оказывает конкретный эксперт, формирующий набор активностей, порядок их следования, добывающий необходимую для принятия решения информацию. С другой стороны, CM предполагает интенсивные коммуникации между различными экспертами, отвечающими за определенные аспекты процесса.

Моделирование деятельности такого рода требует от нас более глубоко изучения к подходам по моделированию бизнес процессов. Из литературы Хенк выбрал три подхода к моделированию процессов:

  • Activity-based
  • Artifact-based
  • Communication-based

Первый подход знаком нам по BPMN и BPEL и характеризуются четко отсортированной последовательностью задач. При использовании третьего подхода цель процесса достигается в результате серии взаимодействий между участниками. А вот второй подход достаточно интересен. Он лежит в основе множества специализированный ИТ-решениях, однако в должной степени не стандартизирован.
В основе artifact-based подхода лежит понятие бизнес-объекта. Наиболее частым примером бизнес-объекта является «заказ» (это может быть заявка на приобретение товаров в интернет-магазине, заказ на предоставление услуги и т.п.) . Бизнес-объект обладает множеством различных свойств, таких как уникальный идентификатор, дата создания, результат проверки кредитной истории, ожидаемая дата поставки и т.п., а так же набором состояний: «новый», «ожидает проверки», «выполнен».

Case managment претендует на объединение всех трех изложенных подходов. Задача, безусловно, амбициозная, но… вполне реализуемая. По крайней мере, такие модные фишки как архитектурный стиль REST и семантический web направлены на универсализацию представлений объектов и отношений между ними.

Одним словом, чем дальше, тем интереснее

Ключевые моменты Case Management

По статье Хенка де Мана Case Management: A Review of Modeling Approaches

Хенк де Ман, research director компании Corsys, выделил следующие особенности case management (далее CM):
1. Центральное место в управлении кейсами занимает непосредственно кейс. Так в здравоохранении, из которого проистекает направление СМ, «история болезни» пациента накапливает всю необходимую информацию и определяет дальнейшие действия терапевта.
2. CM предполагает сотрудничество и коммуникацию. Кроме того, участникам обработки кейса придется реагировать на новые события
3. Как правило, действия сотрудников обслуживающих кейс, строго не предопределены. Эксперту понятно, что необходимо сделать в текущей ситуации, а дальнейшие действия вытекают из результатов первого шага.
4. Цель является более ясной, чем путь её достижения. Для достижения цели возможны различные пути. Выбор того или иного конкретного пути будет определяться в ходе достижения цели, а не планироваться заранее.
5. Исполнитель кейса – это эксперт (knowledge worker), владеющий навыками, которые позволяют ему иметь определенную свободу в принятии решения, в рамках зоны своей ответственности.

Что интересно в этих характеристиках. Во-первых, произнеся слова сотрудничество, коммуникация, сбор информации и knowledge worker мы моментально попадаем на территорию социального ПО, т.е. для корпораций – область Enterprise 2.0. Во-вторых, мы не расстаемся с такими понятиями как роли, активности, последовательность действий и пр., т.е. продолжаем пребывать на территории BPM. Одним словом, нас ожидает микс наиболее узнаваемых ИТ идей текущего момента social software и BPM

Продолжение: Case management и модели процессов

Case management: недостающее звено проектного управления

Управление бизнес-процессами(BPM) и управление проектами, вроде бы, расположены на разных полюсах видов деятельности современного предприятия. Но в действительности, сходства между ними существенно больше, чем это видится на первый взгляд. В обоих случаях нам предстоит выстроить цепочку скоординированных действий различных участников для достижения совместного результата. Потому и проблемы у проектного и процессного управления довольно схожие. И, пожалуй, главная из них это регулярное возникновение непредвиденных событий, отправляющая наш проектный план или же диаграмму бизнес-процесса в мусорную корзину. В проектном менеджменте этому пытаются противостоять при помощи дисциплины управления рисками. BPM предлагает несколько иной подход. И нельзя не признать, что за последние 2-3 года BPM сообщество продвинулось в решении данного вопроса. Одно из названий этого направления Case management.

Обсуждение тонкостей перевода см. в журнале Анатолия Левенчука:
Case management перестало рассматриваться только как работа с кейсами пациентов в клиниках и клиентов юридических бюро. Это теперь такой BPM мейнстрим… далее

Мы же вернемся к существу предложенного подхода.
Значительная часть усилий по управлению бизнес-процессами направлена сейчас на стандартизацию и унификацию деятельности предприятий. Это обусловлено предположением о том, что простота и прозрачность процессов ведет к улучшению управляемости и большей эффективности. В целом, это, вероятно верно, но реальность такова, что нам приходится постоянно сталкиваться с тем, что деятельность интеллектуальных работников (knowledge workers) крайне сложно, если вообще возможно, описать четко детерминированными алгоритмами и правилами.

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

Карьеру в информационных технологиях я начал с разработки систем криптографической защиты информации.

В 1995 году меня пригласили работать в ОАО АБ «Инкомбанк» в качестве эксперта по системам цифровой подписи. На протяжении нескольких лет я занимался разработкой и сопровождением систем межбанковского документооборота и систем «клиент-банк».

С 2000 по 2014 год работал в ОАО «Вымпелком» (торговая марка «Билайн») на разных позициях: ‘эксперт по информационной безопасности, менеджер проектов по развитию value-added services, руководитель отдела проектирования ИТ-систем. В настоящее время руководитель департамента архитектуры систем поддержки бизнеса. Текущие профессиональные обязанности включают организацию разработки ИТ-архитектуры для проектов компании, управление текущей и построение целевой архитектуры, интеграцию приложений.

В 2015-2016 г.г. Главный архитектор информационных систем Банка России

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