97 вещей которые должен знать solution arcitect - 17
2020-02-04 14:51:12 +0600 +0600
Управляет бизнес / Business Drives
В контексте разработки бизнес-приложений, архитектор должен действовать как мост между бизнесом и технологическими сообществами, представляя и защищающая интересы каждой стороны по отношению к другой, часто являющаяся посредником между ними, позволяя управлять процессом разработки ребятам из бизнеса. Цели и реалии бизнес-организации должны быть тем светом, в котором архитектор руководит принятием решений, ориентированных на технологии.
Предприятия регулярно планируют и формулируют конкретную, желаемую рентабельность инвестиций (ROI) прежде чем предпринимать инициативу разработки программного обеспечения.
Архитектор должен понимать желаемое ROI и, как следствие, пределы ценности инициативы в области программного обеспечения для бизнеса, чтобы избегать технологических решений, которые могут привести к тому, что возможность будет израсходована.
ROI должен служить основным предметом объективного контекста в разговорах с бизнесом о взаимных уступках о значении функции в сравнении со стоимостью доставки этой функции, а вместе с командой разработчиков - о техническом проектировании и реализации.
Например, архитектор должен проявлять осторожность, отстаивая интересы бизнеса для команде разработчиков, не соглашаясь выбирать технологию, которая имеет неприемлемо дорогостоящие последствия в области лицензирования и поддержки, когда программное обеспечение развернуто в тестовом энвайроменте или в дев энвайроменте.
Один из вызовов, стоящих перед архитектором для того что бы позволить бизнесу рулить, является предоставление достаточно качественной информации об усилиях прилагаемых командой разработки по разработке программного обеспечения обратно в бизнес для поддержки правильных decision making процессов.
Вот где прозрачность становится решающей.
Архитектор в сочетании с управлением разработкой должен создать и развивать средства для регулярных, постоянных циклов обратной связи с заказчиком.
Это может быть достигнуто различными методами разработки программного обеспечения, такие как большие видимые диаграммы, непрерывная интеграция и частые выпуски рабочего программного обеспечения для бизнеса, начинающийся в начале проекта.
Разработка программного обеспечения - это, по сути, проектная деятельность, поскольку она включает в себя непрерывный процесс принятия решений, пока разработанная система не поступит в продакшен.
Разработчикам программного обеспечения целесообразно принимать множество решений, но обычно не принимать бизнес-решений.
Однако в той мере, в какой бизнес-сообщество не выполняет свои обязанности по обеспечению руководства, ответу на вопросы и принятию бизнес-решений для команды разработчиков программного обеспечения, происходит фактически делегирование принятия бизнес-решений разработчикам программного обеспечения.
Архитектор должен обеспечить макро-контекст для этой непрерывной серии микро-решений, принимаемых разработчиками, путем общения и защиты архитектуры программного обеспечения и бизнес-целей, а также стремиться к тому, чтобы разработчики не принимали бизнес-решений.
Принятие технических решений, не привязанных к комитменту с заказчиком, ожиданиям и реалиям бизнеса, которые постоянно формулируются бизнес-сообществом, приводит к дорогостоящим спекуляциям и часто приводит к неоправданным расходам ограниченных ресурсов.
Долгосрочные интересы команды разработчиков программного обеспечения лучше всего удовлетворяются, когда бизнес драйвит процес разработки.
By Dave Muirhead