Diagrams as code 2.5

Подход “Диаграммы как код” набирает все большую и большую популярность. Простая идея – создавать и редактировать описания диаграмм на некотором формально языке, а потом визуализировать их автоматически – завораживает. Идея не сильно новая. Первое упоминание о программа Graphviz, рисующей картинки, описанные на языке DOT, датируется 1991 годом. Вслед за ней появилось еще много чего. От горячо любимого всеми PlantUML до явно недооцененного сервиса Ilograph Читать далее Diagrams as code 2.5

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

Запись голосового чата в 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, помогающий осуществлять её настройку и развитие. Что об этом думает мой уважаемый читатель?