Модель ключевых концепций бизнес-анализа. Взгляд ИТ-архитектора

Запись голосового чата в telegram 30 марта 2021

IT Architect Assistant – краткий обзор инструмента

Ссылки:

Подписывайтесь на telegram-канал “Архитектура ИТ-решений”: https://t.me/it_arch

Вебинар: Интеграция приложений. Техники анализа и проектирования

Запись вебинара с аналитического онлайн-марафона “Проектные истории”, случившегося 3 марта 2016:

 

Верните аналитика в бизнес (Летний аналитический фестиваль’5)

Презентация на летнем аналитическом фестивале ЛАФ5

[slideshare id=35861344&doc=laf2014maximsmirnovday1-140614013955-phpapp01]

Спасибо организаторам за отличный фестиваль, ЗАО НПО “Консультант” за теплый прием, а участникам за интересное обсуждение.

До свидания, Билайн!

img-20140121121710-502Дорогие друзья! Как вы, возможно, знаете, я покинул позицию Chief IT Architect в компании «ВымпелКом». Предвосхищая вопрос, чем я буду теперь заниматься, я хотел бы сделать несколько анонсов. В ближайшие пару месяцев я не буду работать в режиме full time в какой-либо организации.  Это не значит, что я собираюсь бездельничать, скорее наоборот. На ближайшее время у меня запланировано несколько тренингов, пара консалтинговых проектов и множество встреч с интересными людьми.

Сначала про тренинги. Раньше я уже анонсировал тренинг «Презентация архитектуры ИТ решений: истории в рисунках»,  который состоится 10 апреля 2014 года в ScrumTrek. В двух словах о том, зачем нужен этот тренинг (не читайте описание тренинга на сайте – там слишком многабукв).  Читать далее До свидания, Билайн!

Опрос по архитектуре в ИТ-проектах

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

Анализ требований и проектирование ИТ решений

Последнее время у меня получаются сообщения из серии о единстве и борьбе противоположностей. Управление изменения Standard+Case approach о взаимопроникновении кейс-менеджмента и традиционного подхода к управлению бизнес-процессами, Что такое DevOps о взаимодействии разработки и эксплуатации ИТ-решений и т.д.

Не стану нарушать традицию и сегодняшнее сообщение об анализе требований с одной стороны и проектировании ИТ решений с другой. Казалось бы, эти функции должны быть очень схожи между собой по подходам и методологии, но на практике различия между ними могут быть существенными. Значительно больше, чем между 1-ым и 2-ым уровнем поддержки в ITSM или между разработкой и эксплуатацией. Практически все традиционные методологии развития ИТ решений ориентированы на подход «сверху вниз». Сначала собираем требования, потом проектируем, реализуем, тестируем, развертываем, уходим на следующую итерацию, добавляем новые требования и т.д. без конца. Архитектура больше ориентирована на восходящий подход (bottom-up approach). У нас есть варианты решений(паттерны), мы прикладываем их к задаче и выбираем тот, который подходит наилучшим образом (см. Еще несколько слов о проектировании). Преимущество первого подхода в полноте реализации требований. Сила второго – в простоте, рациональном использовании ресурсов, более высокой вероятности достижения ожидаемого результата.

Однако для того, чтоб системный аналитик мог использовать оба подхода, архитектор должен как следует его вооружить. Иначе каждая новая встреча с заказчиком приведет к сбору требований с чистого листа. Конечно, у хорошего аналитика есть в арсенале определенные знания и навыки, но они имеют слишком общий характер. Аналитик может выделить основные сущности предметной области, определить действующих лиц, набросать варианты использования. Но здесь как в итерационной разработке – самое главное побыстрее пробежать первую итерацию, чтоб в дальнейшем опираться уже на существующее решение. Тогда большинство новых требований окажутся вовсе не новыми, а уточнениями требований уже озвученных ранее.

Я думаю, что значительная часть того, что я пишу в своем блоге предназначено не столько для архитекторов, а скорее для системных аналитиков. Ну а по-хорошему к любой информационной системе должен прилагаться некоторый аналитический framework, помогающий осуществлять её настройку и развитие. Что об этом думает мой уважаемый читатель?

Проблема незаменимых работодателей

Недавняя заметка Проблема незаменимых сотрудников вызвала достаточно много интересных откликов. Я решил продолжить тему и поделится парой мыслей о незаменимых работодателях. Скорее, даже о том, как работодателю сделаться для сотрудника незаменимым. Напомню, в исходном сообщении речь шла об использовании систем adaptive/dynamic case management для передачи знаний и навыков от более опытных сотрудников менее опытным. Говоря другими словами о наставничестве. Не знаю почему, но в последовавших на статью комментариях прослеживалось довольно негативное отношение к этим самым незаменимым сотрудникам. Я решил погугулить и обнаружил массу статей для сотрудников на тему как стать незаменимым и не меньшее число материалов для HR, линейных менеджеров, безопасников и прочих персонажей о том, как с такими сотрудниками бороться. Читать далее Проблема незаменимых работодателей