Раздел III посвящён проектированию информационных систем и охватывает самые «технические» аспекты. Но при этом не нужно штудировать всё залпом — достаточно выбрать, что у вас болит.
Допустим, глава 16 описывает «техническое проектирование»: как внутри системы распределить логику, какие базы данных выбрать, зачем нужна контейнеризация. Если вы туманно представляете, чем занимаются архитекторы и почему обсуждают микросервисы или ER-диаграммы, то здесь вас ждёт прозрение: «Ах, вот оно что, так строится внутреннее моделирование!»
В 17-й главе речь идёт о более широком подходе к архитектуре: микросервисы, распределённые системы, слоистая архитектура, балансировщики, оркестрация — всё то, что часто звучит на командных встречах.
Глава 18 открывает тему интеграции: очереди сообщений, API, брокеры — если вы застряли в вопросах «какими форматами мы обмениваемся с внешними системами?» или «как мы синхронизируем редактуру данных?», вам обязательно туда.
И, наконец, глава 19 покажет, как оформлять задачи на разработку так, чтобы не остаться в недоумении: «Почему у нас всё время разные люди по-разному поняли одни и те же требования?»
Возможные инсайты: «Подождите, значит REST-подход и очереди — это не взаимоисключающие методы?» и «Вместо того, чтобы в четвёртый раз переписывать техническое задание для разработчиков, я могу наконец-то составить критерии приёмки».
Когда функциональные и системные требования более-менее прояснены, наступает этап технического проектирования. Здесь системный аналитик, совместно с архитекторами, ведущими разработчиками и другими заинтересованными сторонами, вырабатывает детальные схемы и спецификации, описывающие техническую реализацию системы: внутренние структуры данных, механизмы интеграции, архитектурные паттерны и принципы взаимодействия компонентов.
В данной главе мы рассмотрим, что такое архитектура в контексте программного обеспечения (ПО) и решений (Solution Architecture), какие принципы и стили встречаются, и почему Systems Design (проектирование систем на более высоком уровне) сегодня приобретает особую актуальность.
Грамотно выстроенная архитектура даёт системе устойчивость к изменениям, возможность расти вместе с бизнесом и быстро реагировать на внешние условия. Недооценка архитектурных вопросов ведёт к хаотичной сборке кода, техническому долгу и трудностям с внедрением и поддержкой. Системный аналитик в связке с архитектурной командой обеспечивает целостность и связь решений с реальными бизнес-задачами.
При грамотном подходе к интеграции удаётся создать целостный IT-ландшафт, в котором информация свободно «переходит» от одной системы к другой, а бизнес-процессы автоматизируются «от конца до конца», без ручного дублирования и ошибок.
В этой главе мы рассмотрим основные принципы и подходы к постановке задач в рамках проектов, какие форматы используются в разных методологиях (Agile, Waterfall), как описывать задачи и критерии приёмки, а также как организовать эффективную коммуникацию вокруг задач.
Грамотно составленная задача переводит требования (часто объёмные) в конкретный шаг разработки, понятный исполнителю и проверяемый приёмкой.