Не жалейте времени на то, чтобы обеспечить быструю работу с системой. Это повышает эффективность труда, устраняет поводы для уклонения сотрудников от работы и в конечном итоге способствует ускорению процесса разработки. Создавайте суррогаты и симуляторы, устраняйте зависимости, делите систему на меньшие модули — делайте что угодно, чтобы у ваших коллег не было даже тени искушения последовать принципу «сделать наспех и сбежать».

Никлас Нильссон (Niclas Nilsson) — консультант и преподаватель в области разработки программного обеспечения, а также писатель, глубоко увлеченный искусством программирования, ценитель хорошей архитектуры и дизайна. Является одним из соучредителей factor10 и редактором материалов в сообществе архитекторов ПО на сайте InfoQ.

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

В технической области единообразие можно ввести принудительно. И для нас это весьма удобно. Однако в сфере бизнеса в игру врывается противоречивый, многогранный, неформальный, хлопотный реальный мир. Что еще хуже, бизнесу приходится иметь дело даже не с реальным миром, а с мнениями людей о тех или иных аспектах ситуаций в тех или иных частях этого мира. Можно, конечно, попытаться отнестись к этой сфере как к технической и внедрить единое решение в приказном порядке. Однако реальность неформально определяется как «то, что не исчезает, когда в него перестаешь верить» (Филип К. Дик), и по мере развития бизнеса проблемы всегда возвращаются. Так возникают команды, занимающиеся корпоративными данными и тому подобным, которые тратят все свое (очень дорогое) время на обуздание экзистенциального ужаса посредством жонглирования DTD. [9]

Время отклика подобных систем обычно оказывается неудовлетворительным с точки зрения заказчика.

Почему бы не принять реальность непоследовательного мира и не допустить существование нескольких несогласованных, перекрывающихся представлений, служб, решений? Да, технический специалист в каждом из нас, услышав такое предложение, съеживается от ужаса. Мы сразу представляем себе кошмарные сценарии: несогласованные обновления, лишние затраты на сопровождение, клубки зависимостей, которыми приходится управлять… Но давайте позаимствуем полезный опыт из мира хранения данных. Витрины данных (data marts) часто денормализуются (в реляционном смысле), в них произвольно смешиваются импортированные и вычисленные значения, а представления данных сильно отличаются от представлений данных в исходных базах данных. И при этом от наличия у витрины данных нефункциональных свойств никакой катастрофы не происходит. На границе двух совершенно разных миров — как правило, операций с данными и аналитической обработки с характерными для них различиями в частоте обновления и выборки, в пропускной способности, в периодичности изменений структуры и, возможно, даже в объемах — находится ETL-процесс. [10] В этом ключ к задаче: достаточно сильные различия в нефункциональных свойствах системы формируют границу, через которую удается организовать практическое управление несогласованными представлениями.

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

Биография автора приведена ранее.

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

Прежде чем браться за проект по разработке программного продукта, коммерческая компания обычно планирует и озвучивает желаемый показатель окупаемости инвестиций (ROI — Return on Investment). Архитектор должен принять этот показатель и вытекающие из него ограничения ценности создаваемого продукта для компании. Это поможет избежать таких технических решений, которые способны привести к перерасходу средств. Показатель окупаемости должен служить важным компонентом целевого контекста как при общении с руководством (в ходе поиска компромисса между ценностью той или иной функции и затратами на ее реализацию), так и при обсуждении технической архитектуры и реализации с командой разработчиков. В частности, перед командой разработки архитектор должен представлять интересы бизнеса, не соглашаясь на выбор технологии с неприемлемо высокими стоимостью лицензии и затратами на поддержку в фазе тестирования или реальной эксплуатации продукта.

Одна из сложных задач, возникающих, когда всем заправляет бизнес, — предоставлять достаточный объем сведений качественного характера о том, как движется разработка продукта, чтобы бизнес-руководство могло принимать обоснованные деловые решения. Здесь важнейшую роль играет прозрачность. Архитектор вместе с руководством проекта должен создать и усовершенствовать средства получения регулярной, оперативной обратной связи. Этой цели можно достичь, применяя различные приемы бережливой разработки ПО (lean software development): большие, заметные диаграммы, непрерывная интеграция, частые выпуски рабочих версий продукта и их передача бизнес-руководству уже на самых ранних стадиях проекта.

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