Архитектура, удовлетворение требований и борьба с неопределенностью.

Что такое архитектура программной системы? Это слово уже настолько замылилось от частого и беспорядочного употребления, что на прямо поставленный вопрос - «А что такое программная архитектура» большинство людей, профессионально связанных с программированием, начинают невнятно лепетать что-то, о фундаментальном, основополагающем etc. Видимо виновато в этом само слово. Очень уж сочно и солидно оно звучит, хоть в русском варианте, хоть в английском. Забавно наблюдать на программистских форумах очередное обсуждение архитектуры, описанной в одном абзаце несвязного текста. Во многих головах существует стойкое заблуждение о том, что архитектура существует сама по себе, живет, развивается, обретает новые формы, и можно приложить ту или иную архитектуру к конкретной ситуации и получить работающее решение. И степень успеха при этом зависит лишь от того, «хорошую» или «плохую» архитектуру мы выбрали. Прискорбное заблуждение, приводящее зачастую к плачевным результатам.

Как получается что, использовав казалось бы «блестящую архитектуру» для построения очередной системы, получаем неутешительный результат? Если попытаться размотать клубок причин и следствий в обратную сторону, то мы обнаружим, что неудовлетворительный результат есть следствие того, что система не оправдала ожиданий пользователей, а ожидания пользователей это, по своей сути, есть не формализованные требования к системе. Т.е. примененная архитектура не обеспечила выполнения всех требований, которые позволили бы оценить систему как успешную. Но ведь архитектура то была «блестящая», в чем же дело? Так и есть, все дело в требованиях. «Блестящая архитектура» удовлетворяла определенному набору требований, но оказалась неприемлемой, когда требования изменились.
Блестящее определение архитектуры, авторство которого мне не известно, но которое донес в незамутненном виде до меня Антон Терехов (Антон, спасибо!) звучит так:

Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению.

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

Вторая проблема похуже первой, и связанна она с тем, что проектирование ПО, это не детерминированный и эвристический процесс. Программу, обладающую фиксированным набором выходных характеристик всегда можно реализовать множеством различных способов. О проектных решениях нельзя сказать ничего определенного до тех пор, пока они не будут реализованы! Часто нельзя быть уверенным будет ли вообще работать то или иное решение, до тех пор пока не сделаешь какой либо макет. Вот что говорит об этом Стив МакКонелл в своей книге “Code Complete”:

«Пректирование - грязная проблема. Хорст Риттел и Мелвин Веббер определили «грязную» проблему как проблему, которую можно ясно определить только путем полного или частичного решения. По сути, данный парадокс подразумевает, что проблему нужно решить один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения. Этот процесс уже несколько десятилетий неразрывно связан с разработкой ПО».

Что ж, лучше не скажешь. Раз за разом, в начале нового проекта приходится сталкиваться этой проблемой. Часто бывает, что не ясно, сможет ли конкретное проектное решение быть реализовано в рамках ограниченного бюджета, или сможет ли оно обеспечить нужную производительность, масштабируемость etc. И если в вопросе с определением требований к системе можно положиться на аналитиков, то ответственность за проектные решения полностью лежит на архитекторе, и это, должен я вам заметить, напрягает.

Подобно тому, как у старого шамана, всегда наготове, помимо бубна конечно, есть целая куча фенечек, типа сушеных летучих мышей, жабьего помета, толченых червяков etc. На любой случай жизни, у бывалого архитектора тоже, помимо бубна конечно, есть наготове набор своих паттернов, снипетов, и просто бесценный багаж негативного опыта прошлых проектов. Бывалый архитектор всегда может усталым голосом сказать: «Ребята, эта фишка не будет работать. Вспомните, на проекте BlueGene восем лет назад они тоже хотели сделать что то подобное, потратили на это полтора мегабакса и у них так ничего не заработало». На то они и бывалый архитектор. Главное, чтобы груз опыта заваленных проектов его совсем не задавил :)