Симуляторы бизнес-процессов

bpsУже не первый год я не перестаю удивляться сценарию внедрения системы управления бизнес-процессами BPMS, разыгрываемому вендорами таких систем. Выглядит это примерно так. После успешной презентации своего решения они собирают команду заинтересованных лиц со стороны заказчика и начинают обучать его рисованию бизнес-процессов в нотации BPMN. Обычно в такую команду входят ИТ-начальники, а также эксперты и руководители функциональных подразделений заказчика. В общем все те люди, которые рисовать процессы скорее всего не будут, ни на бумаге, ни в рисовалках диаграмм, ни в навернутом BPMS инструменте, обещающем реализацию концепции model-driven development. Далее, пару недель эти люди что-то пытаются сделать и потом из тех или иных соображений принимается решение о приобретении или отказе в приобретении рассматриваемой системы. Возможной причиной такого развития событий является отсутствие в организации собственных бизнес-аналитиков (Впрочем, у поставщиков решения их тоже обычно нет, потому как продавец и аналитик – это довольно разные должности. Вряд ли хороший аналитик долго протянет в системе мотивации, выстроенный для sales). Читать далее


Переставляя картинки будущего

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


Requirements as a Service

screenshot_collage

Одно время в моей ленте в FB довольно часто проскакивали сообщения о реестре отечественного ПО. Полное название этого чудесного справочника Единый реестр российских программ для электронных вычислительных машин и баз данных. Кто-то искренне радовался включению в этот список своей программы. Другие искренне негодовали по поводу очередной глупости чиновников. Третьи ностальгировали по временам своей молодости, вспоминая такую штуку, как фонд алгоритмов и программ. Меня же во всей этой истории удивляло только одно: почему во второй декаде XXI века эта штука называется реестр, а не marketplace. Слово реестр устойчиво ассоциируется с документооборотом. Мол есть где-то там сами программы(вероятно в виде распечатанных исходников), но чтоб вам, дорогие друзья,  их самим все не просматривать, мы подготовили для вас единый реестр. Читать далее


Как фальсифицировать agile при помощи microservices

1442365177_2Запись майского вебинара по архитектуре корпоративных приложений получилась не очень качественной и я решил выложить в блог несколько слайдов с этого вебинара, сопроводив их текстовыми фрагментами.  Неоднозначно был воспринят вопрос о соотношении между гибкими методологиями разработки и архитектурой приложений. Стараниями руководителя банка, название которого консультанты, почему-то, не любят произносить, тема гибких методологий обрела второе дыхание. Появились новые статьи в журналах, активизировались учебные центры, а некоторые организации уже вступили в борьбу по сокращению time-to-market. Мало кто из крупных организаций доволен скоростью внесения изменений в свои ИТ-ландшафты и эта неудовлетворенность часто приводит к запуску «проекта по внедрению agile». Тем более, что после появления несколько лет назад коротенькой книжки с надпись SCRUM Guide, сделать это не очень сложно. Читать далее


16-17 июня. Тренинг по архитектуре ИТ-решений

sagraphХочу совсем кратко рассказать об изменениях, которые случились в формате и содержании тренинга по архитектуре ИТ-решений и которые я впервые представлю уже в июне в курсе ITARC «Разработка и управление ИТ-архитектурой»,  организованном компанией IT Expert. Мы затронем два основных вида деятельности solution architect: выбор и защита варианта реализации ИТ-проекта и декомпозиция решения — определение набора изменений, необходимых для реализации проекта. Читать далее


Запись вебинара: архитектура ИТ-решений (IT Expert 28 апреля 2016)


Вебинар: Архитектура корпоративных приложений. Web-scale IT, DevOps, Microservices

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

Подробное описание вебинара и ссылка на страницу регистрации на сайте IT Expert: Архитектура корпоративных приложений.  Web-scale IT, DevOps, Microservices


Отображение пути вместо рисования связей

incДля упомянутого в предыдущем сообщении вебинара я нарисовал простую картинку (см. рисунок, кликабельно). Я не следовал какой-то строгой нотации в этом наброске. Моей целью являлось в двух словах рассказать о том, что такое система управления инцидентами, какие акторы (действующие лица) участвуют в работе с такого рода системой и как выглядит процесс решения инцидента. Главным характеризующим свойством такого рода процессов является наличие двух уровней поддержки. (Иногда выделяют большее количество уровней, но для нас сейчас это не принципиально) На первом уровне происходит классификация обращения и назначение его на соответствующую группу второго уровня. Иногда инцидент может быть решен и на первом уровне. Есть даже специальный KPI, именуемый First Line Resolution Rate, который показывает долю инцидентов, закрытых первым уровнем поддержки. Читать далее


Вебинар: архитектура ИТ-решений

Вебинар: архитектура ИТ-решений

Уже скоро. 28 апреля, в четверг с 11:00 (MSK). Подробности и регистрация: http://www.itexpert.ru/rus/webinar/


Уровни зрелости разработчиков интеграционных решений

esbЛет 7-10 тому назад, во времена всеобщего увлечения сервис-ориентированной архитектурой было модно придумывать уровни зрелости SOA сервисов. Open Group придумал Service Integration Maturity Model (OSIMM). IBM отметился свое трактовкой уровней зрелости (см., например Solution design in WebSphere… ), обещающий достигнут пятого из семи возможных уровней зрелости посредством внедрения WebSphere Process Server  (см. рисунок ниже). Ну, а Microsoft c Informatica-ой занимались оценкой уровней зрелости в деле интеграции данных (A Maturity Model for Data Integration) В общем, каждый занимался своим делом. IBM даже порывался сделать у нас консалтинговый проект, но мы сами приписали себе второй или третий уровень зрелости и сразу согласились на пилотный проект с WS Process Server.По результатам пилота мы даже приняли решение внедрить BPEL Engine, правда не от IBM-а, а open source, да и WebSphere Message Broker из эксплуатации вывели (кому нужен инструмент не того уровня зрелости😉 Читать далее


Отслеживать

Настройте получение новых записей по электронной почте.

Присоединиться к ещё 141 подписчику