Зачем организациям Enterprise Service Bus

050833689Я много раз рассказывал о том, что сервисную шину в компании мы использовали не по назначению. Мы не разрабатывали сервисы для того, чтоб предоставлять их внешним приложениям для доступа к данным и операциям других систем, как это описывается в сценариях интеграции приложений. И пусть простят меня команды, которым пришлось использовать эти сервисы: разработчики мобильных приложений, сервисных платформ и т.д. Эти решения делались не для вас. Сервисную шину мы использовали для того, чтоб разрабатывать сервисы для наших клиентов в строгом соответствием с гартнеровским pace layer подходом. Читать далее…

Роль ИТ-архитектора в организации

a5931_list_of_cell_phone_providers_6865783407_6023ee9464Несколько месяцев назад я написал заметку Когда, кому и зачем нужна Архитектура Предприятия Справедливости ради надо отметить, что полномасштабный проект по выстраиванию Enterprise Architecture  встречается достаточно редко. Намного чаще услуги архитектора бывают востребованы для решения более локальных задач: структурирование приложений, процессов и данных в рамках отдельного продукта, бизнес-функции или направления деятельности организации. В таких случаях обычно говорят об архитектуре ИТ-решения, а человека который её делает называют Solution architect. Одной из задач этого уважаемого эксперта является разработка архитектуры в ИТ-проекте. На прошлом месте работы мы называли эту деятельность High Level Design Но у Solution architect есть еще одна, не менее важная задача – подготовка вариантов решения. О том как это сделать можно почитать здесь Create a solution architecture А я напишу несколько слов о том, почему это важно. Читать далее…

Stage-based case management

Simple-kanban-board-Это сообщение меня побудил написать более глубокий разбор стандарта Case Management Model and Notation и презентация с прошлогоднего PegaWORLD 2013, которая так и называется  Stage-based Case Management.

Я все больше склоняюсь к суждению, что уже привычные нам рассуждения приверженцев адаптивного управления кейсами о непредсказуемых процессах могут многих ввести в заблуждение. Четыре года назад я обратил внимание на adaptive case management не потому, что он позволял работать с волшебными unpredictable процессами. Просто, традиционные BPMS системы не могли удовлетворить наши потребности. Мы потратили много времени на то, чтоб повыбирать решения этого класса. Сделали пару пилотных проектов, но не получили желаемого результата. И дело здесь не в том, что нам требовались средства, автоматизирующие преимущественно совершаемые людьми операции. Скорее наоборот. Основная деятельность была и так автоматизирована в полном объеме. Поэтому внимание было сосредоточено не на процессах предоставления сервиса, они и так работали, а на процессах продажи, обслуживания и поддержки. И вот эти, ориентированные на клиента, процессы и не ложились в рамки стандартного BPMS. Читать далее…

Рубрики:BPM Метки: , , , ,

Case Management Model and Notation. Снова про внедорожник для бизнес-процессов

SmartProcessCrossoverУ нашего восприятия есть одна интересная особенность. Когда мы концентрируемся на каких-либо одних аспектах, то склонны совершенно упускать из виду другие. Классический эксперимент, подтверждающий этот факт, был проведен профессором психологии Дэниэлом Саймонсом и назывался «невидимая горилла». В ходе эксперимента группа людей в футболках разного цвета бросает друг другу мяч, а испытуемые подсчитывают количество передач и не замечают прошедшую по сцене гориллу (см. видео).  Другой пример ограниченности нашего восприятия можно получить, разглядывая картинку внизу этого сообщения.

Вероятно, та же закономерность лежит и в основе того, что любители управления бизнес-процессами скептически относятся ко всему, что связано с темой adaptive case management (Впрочем, верно и обратное утверждение). Как того и следовало ожидать, появившийся в мае этого года OMG стандарт Case Management Model and Notation, вызвал в сообществе BPM определенное недоумение. Зачем нужен стандарт на кейс-менеджмент? Разве кейс-менеджмент это не то же самое, что и agile – делаем все что хотим и будь что будет? Постараюсь немного развеять это заблуждение. Читать далее…

Рубрики:BPM Метки: ,

Описание унаследованных приложений

chinese-slum-01Чаще, чем бы того хотелось, встречается ситуация, когда у нас есть работающее приложение, но на него нет внятного описания. Кто-то и что-то об этом приложении знает. Имеются отрывочные описания структуры данных, а, быть может, нескольких последних изменений, но общей картины все равно нет. Рано или поздно всеобщее желание описать такую систему прорастает в организованную активность. Иногда это вызвано желанием полностью переписать приложение или же отдать его развитие и поддержку на аутсорсинг. Бывает, что мы хотим разобраться с причинами имеющихся с приложением проблем. В общем, типичная задачка, для решения которой зовут архитектора.

Эта заметка не для архитектора, которому поручили сделать описание унаследованного приложения  (legacy application). Это сообщение предназначено тем, у кого возникла такая потребность. Предыдущие пару месяцев я посвятил общению с крупными системными интеграторами, предлагающими такую услугу. Пожалуй, главное, что я вынес их этих разговоров: называть услугой работы по описанию унаследованных приложений несколько преждевременно. Спрос есть, предложение есть, а услуги нет. Нет устоявшегося набора подходов к решению такого рода задач и конкурентной среды, которая и формирует из предложений услугу. Если не рассмотреть несколько альтернатив, то высока вероятность того, что вам, кроме действительно необходимых работ, впихнут в предложение огромный объем дополнительных услуг, реализующих их инструментов и соответствующих экспертов. А потому, рекомендация номер один: Читать далее…

Рубрики:Software architecture

Портал самообслуживания для сотрудников

cartТретью неделю размышляем с коллегами о том, какой бы могла быть идеальная система заявок на ИТ-услуги и другие общие сервисы (управление персоналом, административные заявки и пр.). Скорее всего, такой системы никогда не будет. Однако, полезно иметь в голове некоторый спектр возможных решений в котором с правой стороны расположена вот такая неосуществимая система-мечта, а слева – проект замены старого итилиума на новый. В общем, проделываем  такое, достаточно теоретическое упражнение. Процесс заключается в постепенном отбрасывании тех или иных стереотипов мышления и постепенно получается некоторый набор тезисов о том, как может выглядеть такой портал. Как говорится, здесь пока оставлю, пусть повесит. Читать далее…

Рубрики:Enterprise 2.0 Метки: , , ,

Архитектура корпоративных знаний

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

Рубрики:Enterprise 2.0, Semantic Web
Отслеживать

Get every new post delivered to your Inbox.

Join 90 other followers