Здесь хочется сделать некоторое отступление. Я часто встречал такой стиль работы архитектора системы : 1) ждем требования от владельца продукта 2) обрабатываем их по мере поступления
Лично мне такой неактивный подход не близок, но он весьма распространен. Что может получиться при таком подходе: общую конструкцию мы поймем в самом конце и можем получить на выходе не то, на что рассчитывали . Т.е. проектировали легковой автомобиль, к концу требований поняли, что нужен пикап с прицепом.
Мой опыт показывает, что наилучшей схемой в паре владелец продукта - архитектор должно быть так, что бы
архитектор чуть-чуть должен быть владельцем продукта,
владелец продукта должен быть немного архитектором.
Как архитектору надеть «шапку» владельца продукта более или менее понятно – нужно понимать бизнес, для которого создается продукт – цели, задачи, принципы, общие практики и все такое прочее.
А вот как владельцу продукта надеть «шапку» архитектора? Ниже я приведу некое «Краткое наставление по проектированию» для владельца продукта. Если в паре владелец продукта - архитектор будет такая схема – успех продукта более вероятен.
По сути попробуем описать, на какие вопросы, в части архитектуры, владелец продукта должен подготовить ответы, чтобы с минимальными трудозатратами зайти в «Федерацию», а через нее в корпоративную архитектуру распределенной организации.
Тут важно заметить, он (владелец) может и оставить вопрос без ответа, но вопрос все равно не исчезнет.
Итак, освой проектирование технологических продуктов за 16 минут:
Потенциальный рынок : для кого владелец продукта готов предлагать свой продукт? Нужно критически посмотреть на себя, на что меня хватит, к чему я готов. Часто бывает : у меня отличное решение, готов на любое внедрение, а заказчик потом говорит — а на 10 организаций — сможешь?, а за границу? Тут начнется: мне нужно 2 месяца на загран паспорта, нанять 100500 человек, а вы пока подождите. Так неопрятно. Назвался груздем — полезай в каталог «Групповых прикладных решений». Не готов — не лезь. Все по‑взрослому.
Специализация: нужно четко определить, на что рассчитан продукт, на какой функционал делался акцент при проектировании. Где продукт будет особенно хорош. Можно «продать» CRM как полноценный MDM клиентских данных, но это не его основанная функция и это нужно понимать. Можно и чайной ложкой есть суп, но она создавалась, все же для чая.
Приземление на "принимающий" ИТ‑ландшафт: Любой продукт помещается в какой‑то ИТ‑ландшафт для создания какой‑то ценности, но ему может что‑то понадобиться в «принимающем» ИТ‑ландшафте, или ему нужно будет с чем‑то интегрироваться по требованиям «принимающей» стороны. Отсюда для такого продукта нужно определить функциональные «вилки/розетки». Пример, мы поставляем двигатель, его предоставляемые функции (т. е. ценность для потребителя) — вращающий момент, ему в "принимающей" конструкции нужны: топливная система, трансмиссия и т. д. (вспомогательные функции), и наконец заинтересованные функции, для двигателя - это система отопления салона. т. е. владелец продукта так должен декомпозировать свой продукт (двигатель), чтобы он встраивался в большинство ИТ‑ландшафтов (автомобилей). Если он этого не сделает, то может случится так, что у него какая‑то функция так «прибита» к архитектуре системы, что «не отковырять», а кому‑то эта функция не нужна, есть своя. В примере с двигателем, не нужно приваривать к двигателю кардан, а то и получается «невпихуемое» решение и будешь сам себе злобный Буратинка.
Компонентная структура: Все выше описанное должно быть отражено в архитектуре системы. Есть функции твоего продукта, есть вспомогательные и заинтересованные функции — и это должно быть отлито в архитектуре системы. т. е. эти функции в этом модуле, эти в этом и т. д. На какие части можно «разобрать» систему, что можно взять, а что заменить на свое или продукт от другого производителя. Кому‑то это не важно, хоть монолит приноси, а кому‑то нужен «конструктор».
Комплектация: четко декомпозировали функционал, теперь нужно сформировать доступную комплектацию — Home Edition, Standard Edition, с перламутровыми пуговицами. Нужно показать, какие есть возможности по использованию продукта. Кому‑то полный комплект, кому‑то на полшишечки.
Вилки/розетки: и как финал декомпозиции нужно определить линии «разреза», т. е. внутренние и внешние API системы и зафиксировать эти линии в спецификации API — т. е. контракты частей системы между собой и с внешними потребителями
Качество: и на «пятерку» — качество предоставляемого сервиса (QualityOfService) или в простонародье — SLA. Под какие нагрузки и условия эксплуатации рассчитан наш двигатель. Рассчитан тащить 200 т груза или разогнать машину до 300 км/ч, хлебать суп или помешивать сахар в чае.
Приведенный подход дает возможность владельцу продукта посмотреть на свой продукт глазами архитектора и формулировать требования.
В таком парном проектировании больше вероятность получить отличный продукт, который подойдет максимальному количеству участников нашей Федерации.
Кому понравилось наставление – используйте, а кому нет – ну и ладно.
