97 этюдов для архитекторов программных систем

Обязательно изучите перекрытия логических областей и функциональности инфраструктур-кандидатов. Если понадобится, нарисуйте диаграмму Венна. Две модели данных, существенно перекрывающиеся в предметной области, или две реализации, решающие очень похожие задачи немного различающимися способами, порождают излишнюю сложность: придется находить соответствия между концептуальными различиями или представлениями либо приделывать заплатки из неуклюжего связующего кода. В итоге вы, скорее всего, получите не только громоздкий связующий код, но и сведете функциональные и репрезентативные возможности системы к наименьшему общему знаменателю двух инфраструктур.

Чтобы снизить вероятность функционального перекрытия, выбирайте инфраструктуры с высоким отношением полезной нагрузки к балласту в контексте требований вашей системы. Полезная нагрузка — это функциональность или возможности представления данных, необходимые вашему проекту, а балласт — то, насколько инфраструктура стремится охватить все что можно и решить все задачи на свете. Требует ли инфраструктура смешивать управление данными и их представление? Как сильно ее модель данных или набор пакетов/классов выходят за пределы того, что необходимо вашей системе? Придется ли вам присягнуть ей на верность и впредь ограничить выбор инфраструктур теми, что соответствуют ее рамкам? Ограничивает ли ее избыточная сложность возможности взаимодействия? Если уж инфраструктура отягощена большим количеством балласта, она должна обеспечивать хотя бы 75 % необходимой функциональности проекта.

Система должна состоять из неперекрывающихся инфраструктур — блистательных в своей области, но при этом простых, компактных и гибких.

Эрик Готорн (Eric Hawthorne) профессионально занимается созданием архитектуры, проектированием и разработкой объектно-ориентированных программ и распределенных систем с 1998 года. Первые 10 лет его карьеры прошли в Macdonald Dettwiler — канадской системотехнической компании, где среди прочего он имел возможность поучиться архитектурным тонкостям у самого Филиппа Крачтена (Philippe Kruchten).

Подготовьте убедительное экономическое обоснование И Чжоу

Приходилось ли вам как архитектору программного обеспечения сталкиваться с трудностями финансирования архитектурных проектов? Преимущества того или иного архитектурного решения очевидны для архитекторов, но для заинтересованных в проекте сторон это зачастую не так. Психология массового сознания говорит, что большинство людей склонно верить лишь тому, что видит собственными глазами. Однако на ранней стадии проекта трудно продемонстрировать заинтересованным сторонам что-то, что может стать убедительным доводом в пользу качественной проработки программной архитектуры. Еще сложнее дело обстоит в отраслях, не связанных с программированием, где заинтересованные стороны обычно очень слабо разбираются в программных технологиях.

Психология массового сознания говорит также, что большинство людей считает воспринимаемое реальностью. А значит, если вы сможете управлять тем, как люди воспринимают предложенный вами подход к решению тех или иных архитектурных вопросов, вы практически гарантированно сможете управлять и их реакцией на ваше предложение. Как управлять восприятием заинтересованных сторон? Подготовьте для своей архитектуры надежное экономическое обоснование. Люди, которые финансируют ваши идеи, почти всегда руководствуются деловыми соображениями.

На протяжении своей карьеры я неоднократно применял следующий процесс из пяти шагов для успешного продвижения своих архитектурных решений:

1. Сформулируйте ценностное предложение. Составьте пояснительную записку относительно того, почему деловые интересы вашей организации требуют применения определенной программной архитектуры. Для этого необходимо сравнить предлагаемые вами архитектурные решения с имеющимися решениями или возможными альтернативами. Основное внимание следует уделить возможности повышения производительности и эффективности бизнеса, а не замечательным свойствам технологий.

2. Предложите количественные метрики. Польза от предлагаемых вами решений должна быть измеримой (до разумной степени). Чем больше количественных показателей вы предъявите, тем убедительнее сможете обосновать свое утверждение о том, что предлагаемая архитектура обеспечит существенную отдачу. Чем раньше будут заданы метрики, тем проще вам будет управлять восприятием заинтересованных сторон — а это поможет вам убедить их в преимуществах своей архитектуры.