Рубрика: Без рубрики

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

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

[slideshare id=32610494&doc=architectureagile-140322100834-phpapp02]

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

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

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

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

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

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

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