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