Что такое «ИТ-решение»

t7oRaЯ в своем блоге давно не анонсировал тренинги и учебные курсы. Начинаю исправлять это упущение. Сегодня чуть подробнее о тренинге Solution Architecture. Несколько абзацев о том, кто такой solution и зачем ему нужна архитектура.  Можно конечно просто сослаться на определение solution architecture из TOGAF:

Solution Architecture A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.

но вряд ли из него станет более понятным, о чем этот тренинг. Поэтому, ряд комментариев.

Понятие «ИТ-решение» зазвучало в конце прошлого века вместе с появлением итерационных методологий разработки ПО: RUP, MSF и т.п. Думаю, большинство читателей помнят красивые спиральные картинки с изображением  этапов разработки информационной системы – анализ, проектирование, разработка, тестирование, развертывание и т.д. В разных методологиях было разное количество этапов, но суть от этого существенно не менялась. Целесообразность присутствия этих этапов была очевидна из многолетнего опыта разработки и у большинства айтишников сомнения не вызывала. Всем более-менее понятно, что сначала не плохо бы определиться с тем, что же именно мы хотим сделать, параллельно с разработкой ПО надо бы запустить закупку серверов, интеграция займет времени не меньше чем разработка, да и пользователи не станут  работать с новой системой без инструкций, обучения и прочих полезных вещей. В общем, мало кто сомневался в том, что работать следует так. Читать далее…

Рубрики:Software architecture Метки: ,

Зачем организациям 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 Метки: , , ,
Отслеживать

Get every new post delivered to your Inbox.

Join 89 other followers