Архитектура ИТ-решений

Лет 10 назад я увлекался штукой, которая называется adaptive case management (в других источниках слово adaptive заменялось на dynamic или даже advanced). Этот термин обозначал особый вид бизнес-процессов, для которых не всегда можно указать правильную последовательность шагов, ведущую к цели, да и не так уж она важна по сравнению со спецификой данного конкретного случая. Здесь есть некоторая игра слов, даже смыслов. Слово кейс, с одной стороны, обозначает портфель или папку с бумагами (материалы дела, история болезни и т.п.), а с другой - некоторый уникальный прецедент, требующий своего подхода или решения (кейс, при обсуждении успешных примеров в бизнес-школе). Обычно с кейсом работает специально назначаемый на него человек – case worker (лечащий врач, адвокат, в общем knowledge worker), который и решает, что, когда и зачем следует делать в сложившейся ситуации.

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

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

Хорошей вам пятницы, друзья!

👍3

5.93K views07:20