ОРГАНИЗАЦИОННЫЕ И АРХИТЕКТУРНЫЕ СТРУКТУРЫНе успели мы написать раздел 7.3, в котором приводится пример связи между организационной и архитектурной структурой, как один знакомый специалист по телекоммуникациям предложил свой пример. Организация, о которой он рассказал, считает необходимым оперативно реагировать на жалобы клиентов и предложения о модификациях. Согласно этой схеме, исполнение каждого исходящего от клиента запроса на внесение изменений вменяется в обязанность определенному специалисту. Любое изменение предусматривает корректировку ряда архитектурных компонентов, а это значит, что участники группы реагирования на запросы заказчиков, вынужденные работать с системой в целом, должны стоять особняком от любых других групп, ответственных за те или иные компоненты. Таким образом, организационная структура, подстроенная исключительно подструктуру архитектурную, оказывается неадекватной реалиям Такой рас клад сначала сбил нас с толку. Но, приступив к подробному допросу информатора. выяснили, что каждая модификация в этой компании проводилась дважды: первый аз (оперативно) службой работы с заказчиками, а второй — теми группами разработчиков, вторые были ответственны за соответствующие компоненты. Любые другие схемы способны в сжатые сроки угробить архитектуру - разве только каждый компонент в ней реализует для конечного пользователя одну, четко определенную функцию. Теперь поподробнее о нашем последнем утверждении. Архитектура, как мы неоднократно заявляли, призвана удовлетворять многим, зачастую входящим друг с другом в противоречие, требованиям. Архитектура, в которой каждый компонент реализует для пользователя одну функцию, прекрасно удовлетворяет требованиям по модифицируемости — если только модификация не затрагивает физические элементы, воздействующие на другие функции. На этапе сопровождения, как в изложенном нашим коллегой контрпримере, такая архитектура локализует модификации любой конкретной функции в одном-единственном компоненте. С другой стороны, такая «функциональная» архитектура, естественно, не предусматривает возможностей повторного использования компонентов и совместного использования данных, что делает ее весьма неэффективной с точки зрения реализации. На самом деле компания, о которой идет речь, стремилась довести повторное использование до максимума и, в расчете на достижение этой цели, организовала рабочие единицы в точном соответствии с компонентной структурой. Поскольку любая модификация (потенциально) касается нескольких организационных единиц и их действия необходимо согласовывать (читай: чем больше рабочих групп задействовано в процессе модификации, тем более замедляется реагирование), компании пришлось сформировать группу быстрого реагирования, но в результате каждую модификацию приходилось проводить дважды. -LJB В главе 1 мы говорили о том, каким образом на характер архитектуры влияют организационные факторы — прежде всего опыт, а также желание применить или развить те или иные навыки. Вышеприведенный сценарий являет собой конкретный пример этого явления. По мере того как компания продолжает работу в той или иной предметной области, она вырабатывает артефакты, применяемые для выполнения задач, а обязанность по их поддержанию ложится на ее организационные группы. Более подробно мы поговорим об этом в главах 14 и 15, посвященных линейкам программных продуктов.
|
