Записки правдивого архитектора: просто о самом главном (Ч.1)

Все нижеизложенное является исключительно частным мнением автора, не имеющим отношения к какому-либо работодателю либо вендору.

«Хмм… правдивого архитектора… А что, такие бывают? – спросите вы и подумаете. — Врет, поди! Сейчас будет нам рассказывать очередную концепцию „бла-бла-бла.2.0“. Знаем, плавали, видали мы „витающих в небесах архитекторов“ и их умозрительные конструкции».
И будете правы: нормальный «пацанский» архитектор — человек очень занятой, и времени писать статьи у него, как правило, нет… Но! Бывает, что настает момент – и желание человека поделиться опытом, рассказать о своих удачах и сложностях миру настолько высоко, что и время находится, и присущий нашему брату-технарю страх публичных высказываний отступает. К тому же коллеги по цеху давно призывали меня начать подобную деятельность.

Стартовать я решила с темы несколько общего характера – ИТ-архитектуры в целом. Почему бы сразу не перейти непосредственно к деталям, которые наиболее занимают читателей технических блогов?
Ответ прост: уж больно много вопросов, трактовок и кривотолков возникают вокруг работы и задач архитекторов. И чтобы двигаться дальше, нужно выстроить некую «общую систему координат» — некую отправную точку.
За время моей работы сложилось некое «видение» происходящего, которым хотелось бы поделиться и обсудить с коллегами.

Итак, попробуем поискать ответы на следующие вопросы.

Если вы когда-либо задавались подобными вопросами, и они представляют для вас интерес, то эта статья для вас — приглашаю поразмыслить вместе.

Что такое архитектура?

Итак, начнем «от печки» — попробуем дать определение этому понятию.
Не только архитекторы, но и древние философы обращали внимание на терминологию в своих беседах с досточтимыми правителями государств:
«Если имя неправильно (не соответствует сущности), то слово противоречит делу, а когда слово противоречит делу, то дело не будет исполнено, а если дело не будет исполнено, то церемонии и музыка не будут процветать, а если церемонии и музыка не будут процветать, то наказания не будут правильны, а когда наказания будут извращены, то народ не будет знать, как ему вести себя. Поэтому для благородного мужа необходимо, чтобы он непременно [мог назвать правильные имена вещей с тем, чтобы] сказанное исполнить и чтобы в словах его не было ничего бесчестного (недобросовестного)»
/Конфуций «Суждения и беседы»/

И все-таки я не стану приводить все возможные, замечательные по своей полноте, оригинальности и глубоким смыслам, определения термина «архитектура». Да и нет такой задачи — дать идеальное определение (если это вообще возможно). Главное – это понять суть предмета.
А знаете… я вообще не стану приводить определение. По крайней мере, прямо сейчас. Сделаю это позже.
Даже в такой строгой науке, как математика, как говаривал мой педагог из универа, век идеальных определений давно прошел:
«Не помнишь определение из учебника – и не надо. Попробуй пойти от примеров – и таким образом выстроить понятие».

Итак, Архитектура… Да, именно подобные картинки помещаются частенько на титульный лист архитектурной ИТ-концепции и становятся символом («логотипом») архитектурных подразделений крупных компаний.
Конечно, первое, что приходит на ум – это связь с известной всем областью строительства. Архитектура зданий, сооружений, городов – сфера хорошо известная и имеющая давнюю историю.
Справедлива ли аналогия?
Безусловно! Более чем!
Известны целые исследования на эту тему – например, статья Пата Хелланда «Метрополис».

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

• красота, образ эпохи, эстетическое восприятие;
• удобство и комфорт использования, соответствие целевому назначению;
• технологичность, точность проектных чертежей;
• инфраструктурные /инженерные компоненты (коммуникации, система водо- и электроснабжения);
• безопасность, устойчивость, надежность;
• следование отраслевым стандартам качества

и др.

Можно выделить два основных аспекта, направления, по которому прорабатывается архитектура:

• восприятие человеком;
• технологический аспект.

Стоит также добавить 3й – стандартизация и качество. К сожалению, даже в классическом архитектурном деле, в области строительства порой забывают об этом моменте. Последствия всем известны, и они весьма печальны (в некоторых случаях даже трагичны) …

Абсолютно уместной выглядит аналогия: для того, чтобы построение ИТ-систем и комплексов завершалось успешно – нам так же, как и в строительстве, необходимо задумываться и решать этот набор архитектурных вопросов – прежде, чем бросаться «кодить» или «фигачить».
И отталкиваться при этом надо… Правильно – от назначения.

Первые вопросы, которые мы себе задаем, звучат так:

• Зачем мы это делаем?
• Какие проблемы и задачи есть сейчас? Кого это затрагивает? В чем это выражается? Что будет, если их не решать?
• Как может выглядеть наша «картинка будущего», когда мы это сделаем?
• Каким образом это затронет людей, которые сейчас работает и будет работать с этим функционалом?
• Как это затронет другие системы? Как поменяются информационные потоки внутри компании?
• Кому, как и когда должна быть доступна порождаемая при этом информация? Как она будет соотноситься с другой информацией, генерируемой компанией?
• Какой набор шагов (проектов) мы должны сделать – чтобы прийти к желаемому результату?
• Сколько это будет стоить? Какие есть альтернативы?
• Нам раньше доводилось делать нечто подобное? Что мы хотим взять из этого опыта? Что хотим попробовать сделать иначе? Почему?
• Возможно, кто-то это уже делал? Как они это делали? Какие результаты получили? С какими проблемами столкнулись?
• Мы в это идем, потому что нам это даст…

Как видно, это очень разноплановый перечень вопросов. И все они в той или иной степени имеют отношение к ИТ-архитектуре предприятия. Не все из них находятся «во власти», в зоне непосредственной ответственности архитектора, но они находятся в зоне его влияния. И следующий раздел – как раз об этом. О чем стоит задуматься, прежде чем…

«Вижу цель – не вижу препятствий» или Что такое целевая архитектура?

Есть такая известная во всех крупных компаниях тема – “целевая архитектура”, мифическая и таинственная, почти как любовь: “Все о ней говорят, но мало кто ее видел” /Ларошфуко/
Стало быть, целевая архитектура должна ответить, прежде всего, на вопрос – зачем мы это делаем. Т.е. она обозначает цель, смысл нашей деятельности. И лишь затем мы задумываемся и решаем — каким образом мы будем этого достигать, за счет каких технологий, на каких платформах.

Прежде чем бросаться отвечать на вопрос «как» (делать, внедрять систему, платформу и т.д.) убедитесь, что ответили на вопрос «зачем».

Все просто! И если этого простого (и вроде бы очевидного, не так ли?) шага не сделать, а броситься бегом строить схемы и кодить, кодить, кодить… то есть большой шанс, что этот труд потом улетит в корзину! И в результате посетит и вас, и вашу команду, и ваших заказчиков великая печаль. Задавайте себе этот вопрос не в конце, а вначале своего “забега”.

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

Четко напрашивается, по крайней мере, один вывод: этими вопросами необходимо озадачиться до точки старта проекта. И даже до момента его инициации. “Но как же так?” – может возникнуть вопрос: “Мы же уже давно привыкли, что вся деятельность ИТ осуществляется в рамках проектов, а в случае гибких методов – в рамках спринтов”.
Вот тут начинается интересное… Послушаем, что говорят на эту тему “ведущие собаководы” ИТ-отрасли — т.е. организации, создающие и распространяющие разного рода стандарты и референсные практики.

Так, OpenGroup на этот счет выпустила недавно концепцию IT4IT. Операционная модель ИТ, которая там представлена, включает в себя набор четырех базовых «цепочек создания ценностей» (VAD). Одна из них – “Strategy to portfolio”, в рамках которого и формируется “портфель проектов”, отталкиваясь от того, что мы хотим видеть (целевое видение) и от ситуации as-is (текущая архитектура). Таким образом, через ИТ-стратегию и портфель проектов выстраивается мостик к нашей желаемой «картинке будущего».

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

Таким образом, правильным выглядит такой путь:
Сперва целевая архитектура… Точнее, сперва бизнес-стратегия, потом целевая архитектура, которая ее поддерживает, далее — стратегия ИТ, которая отражает переход от текущего состояния к целевой, и, наконец, в соответствие со ИТ-стратегией – формирование портфеля проектов.
Вот почему архитекторы на предприятии так упорно говорят о целевой, о необходимости соответствия проектов ее руслу, о необходимости фиксации отклонений (временных и обходных решений) и т.д. Это их прямая обязанность. Это их работа. И это их ответственность. И для них важно, чтобы разговоры об архитектуре не носили бесконечный характер, а завершались вполне определенным delivery – и определенными (зафиксированными решениями).

Часто ли так происходит?
Да нет, конечно… В нашу стройную систему вмешивается господин Хаос. Точнее люди, которые сами его создают, осознанно или неосознанно. Однако выбирать не приходится – и нам тоже надо как-то существовать в предлагаемых жизнью обстоятельствах – неопределенности, несогласованности, неразберихи и т.д.
Попробуем разобраться, как все происходит, и что с этим можно сделать.

О целевой архитектуре (как и о любви) можно говорить бесконечно… И поэтому, важно зафиксировать некое видение – получить «картинку будущего». Либо несколько вариантов – несколько «картинок».
Почему важно фиксировать? Казалось бы, очевидный вопрос, но как ни странно, много копьев ломается вокруг этого.
Потому как – целевая архитектура – это наша «опора из будущего». Представьте – какой возникнет хаос в нашем портфеле проектов, если она все время будет меняться?
Кто занимается подобной проработкой и отвечает за качество результата? Конечно, ИТ-архитектор – это его зона творчества, влияния и ответственности. При этом он общается с большим количеством людей, собирает и обрабатывает множество информации, изучает существующие аналоги, что-то пробует. И наконец, предлагает некое целостное решение – архитектурную концепцию. Она и представляется на дальнейшее обсуждение и утверждение как целевая архитектура – сперва в очень общем плане – как концепция или видение.

Когда целевое видение появилось, нужно постараться сделать так, чтобы все влиятельные лица (их принято называть «стейкхолдерами») увидели в ней некую ценность для себя и пришли к согласию относительно нее. Таким образом, критерием останова этого «увлекательного занятия» по обсуждению архитектурных концепций будет сокращение замечаний от принимающих решения людей до некого допустимого минимума.
Как и в любом споре, в процессе архитектурных дебатов людей частенько захлестывают эмоции. Что нам важно? Важно с одной стороны, не упустить какого-либо ценного замечания, возможности или потребности. А с другой стороны – направить процесс в конструктивное русло. Т.е. необходимо все суждения переводить в конкретику. Иными словами, требовать обоснования – как от докладчика, представившего вариант архитектуры на рассмотрение, так и от вопрошающего. Уровень «нравится – не нравится» — не лучший способ выстроить подобный процесс, т.к. он слабо результативен.

Хорошим способом является подход, в процессе которого некое предлагаемое решение «проверяется на устойчивость» — вопросы из серии «что будет если…». Взгляд на 360 вокруг этой темы.

Для упорядочения деятельности по принятию подобных коллегиальных решений в крупных компаниях используют практику «архитектурных комитетов». К участию в них привлекаются люди, которых это в той или иной степени коснется – от бизнеса до ответственных за ИТ-инфраструктуру и сопровождение систем. И концепции проходят утверждение там. Далеко не всегда этот процесс на практике выглядит оптимально и результативно. Но других вариантов пока не придумали.

Выйти в конструктив можно, если

1. не привлекать к участию лишних людей;
2. допускать к обсуждению замечания в рамках своей компетенции (зоны принятия решений и ответственности);
3. приводить только аргументы, четкие и конкретные;
4. иметь ясные критерии выноса вопросов на всеобщее обсуждение и понимание модели/формата этих обсуждений;
5. четко модерировать собрание – придерживаться установленных правил и избегать «базара» (ввести и закрепить правило – в один момент времени говорит только один человек).

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

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

Здесь может возникнуть вопрос, что делать, если действительно такого настроя в данный момент не прослеживается? Можно ли его поменять?
Во-первых, необходимо увидеть и осознать проблему, приостановить дискуссию непосредственно по теме встречи, т.к. когда люди «сели на эмоции» уровень аргументации, логических доводов перестает работать.
Второй шаг – постараться увидеть позитивное намерение человека, который возражает, как нам может казаться, весьма странно – например, переводит фокус внимания к другой больной для него теме, уводит в сторону и т.п. И увидеть свою собственную приверженность, если вас это, в свою очередь, начинает раздражать. Если мы вовремя «поймали момент», и страсти еще не накались, успели «нажать на паузу», осознать и мысленно сформулировать это, то нас уже сложнее будет «выцепить на эмоцию» — уже хорошо.
Третий шаг – «возвращаем» человеку его же намерение, но в позитивной формулировке. Таким образом, ему не просто сказали, что «я тебя слышу», а его реально услышали и дали обратную связь. Хорошо бы это также записать и пообещать вернуться к этому важному и острому вопросу позже. И попросить разрешения продолжить встречу.
Острота спадает, конструктивный настрой остается.
Конечно, это не так просто. Легко написать — трудно сделать. Нужен опыт и тренировка в коммуникациях и переговорах. Эта тема весьма обширна, и раскрыть ее здесь не получится, только слегка наметить и создать уверенность, что такие подходы точно есть, они рабочие, и при желании их можно найти, изучить и проработать на практике (лучше с помощью опытного наставника).

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

Замечу, что «зрелость» по отношению к компании не определяется ее размером или ее возрастом. Бывают довольно крупные компании, которые не отличаются высоким уровнем зрелости: т.е. не стремятся «понять себя» — свой бизнес, своих сотрудников, свои цели. А стратегические инициативы часто носят формальный характер.
В то время как есть стартапы, в которых люди довольно быстро приходят к выводу, что например, одного классного кодинга (если говорить про ИТ-сферу) не достаточно – необходима некая организующая и направляющая сила.
И тому есть реальный примеры. Недавно моего друга-архитектора пригласили поучаствовать в подобном проекте, в котором уже работают хорошие разработчики, работают с драйвом и интересом, на новых технологиях и т.п. И при этом говорят: «как-то странно выходит – кодим-кодим, но как-то… не понятно, к какому результату мы движемся».

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

Сейчас много пишут о том, что банкам грозит конкуренция с ИТ-компаниями. И руководители банков начинают спешно перестраивать практики управления под ИТ – внедряют гибкие методы, покупают ИТ-стартапы и т.д. Но это их не сделает ИТ-компаниями. Почему? Потому что не будут в банках работать люди, которые работают в google или amazon. Это не «их формат». И дело тут не в формальных методах управления разработкой и ведения проектов. Сравните подходы к условиям работы, взаимоотношениям в этих компаниях, способам ведения бизнеса и т.д. В чем разница? Это компании разной культуры, разного «способа жизни». Банк – не ИТ-компания, и никогда ей не будет. (Также как и ИТ-компания никогда не будет банком). Так почему бы банкам… не оставаться банками, исследуя и развивая свои сильные качества? (А они у них, бесспорно, есть, в т.ч. и в ИТ.) Вместо того, чтобы бросаться из крайности – в крайность: то передаем ИТ на аутсорсинг как непрофильную обеспечивающую деятельность, то готовимся к конкуренции с ИТ-компаниями.
И это имеет прямое отношение к вопросу зрелости.
Зрелая компания, какого бы размера, возраста, уровня капитала, географии она не была, к какой бы отрасли она не относилась – знает «себя», видит «свое будущее», понимает свой бизнес, слышит своих сотрудников. И стремится найти и выстроить свой путь развития, а не слепо копирует и примеряет на себя чей-то чужой…
Вспоминая сказку про «Золушку» — как бы ни хотелось выйти замуж за принца, не стоит пытаться отрезать себе пятку, пытаясь влезть в чужую хрустальную туфельку.

У каждой компании свой талант, своя тема. Осознанный подход к развитию архитектуры учитывает специфику компании, задачи, проекта, их уникальность.

Архитектурные стандарты и фреймворки

Теперь настало время обратиться к стандартам. И следуя, заветам мудрого Конфуция, дать ясные определения интересующих нас понятий, чтобы «церемония и музыка» процветали, а «сказанное» было исполнено.

По части ИТ-архитектуры существует несколько детально проработанных стандартов.
Прежде всего, это ISO/IEC 42010: 2007, где можно обнаружить следующее определение:

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

А вот определение из известного архитектурного фреймворка TOGAF от OpenGroup:

Архитектура обладает двумя значениями, в зависимости от контекста:

1. формальное описание системы или детальный план системы на компонентном уровне как руководство к ее реализации;
2. структура компонентов, их взаимосвязей, принципы и стандарты, которым следует руководствоваться в процессе проектирования и развития системы.

Почему я стала говорить об определениях в контексте фреймворков? Что означает само по себе понятие «фреймворк»?

Фреймворк определяет методологию решения задачи определенного класса. От слова «метод» — повторяемый подход, применение которого приводит к предсказуемым результатам.

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

В фреймворке присутствует два взаимодополняющих и разнонаправленных процесса:

• генерализация (обобщение опыта) – с одной стороны;
• адаптация (локализация референсных практик к конкретной ситуации, проблеме, компании) – с другой стороны.

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

Неслучайно требование «адаптивности» все чаще звучит по отношению и ИТ организации. Порой это приводит к неоправданно завышенным ожиданиям – получить возможность решения совершенно разных задач «из одной коробки». Это не всегда оправданно. Есть более эффективный путь – использовать компонентную архитектуру, не перегружая инструменты и технологии несвойственным и избыточным для них функционалом. Такой вариант гораздо прозрачнее и устойчивее в применении. Но он также требует и затрат – уже не достаточно лишь узкого знания некой одной системы – требуется объединить множество систем, интегрировать в единый ИТ-ландшафт.
И роль ИТ-архитектора, его задача – как раз помочь в этом процессе. Он не принимает решений единолично, он собирает и представляет информацию таким образом, чтобы то было понятно многим людям в компании – от бизнеса до инженеров – т.е. подготавливает почву для принятия коллегиального решения. Это не значит, что он не должен обладать технологическими знаниями – как раз наоборот – практика работы с технологиями – один из ключевых аспектов его деятельности. Но как будет показано далее, далеко не единственный.

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

Завершая тему с определениями, приведу еще одно, от компании Oracle, которое, как мне показалось, очень хорошо отражает суть и глубину предмета:

Архитектура – метод и организующий принцип, которые согласуют функциональные задачи и стратегии бизнеса с ИТ-стратегией и планом исполнения.

Кто наш заказчик и какие у него могут быть желания, высказанные и невысказанные

Как и у любого исполнителя, решающего поставленную кем-то задачу, у архитектора есть… правильно – тот, кто ее поставил – т.е. Заказчик! Кто может быть таким заказчиком и как может выглядеть «процесс заказа архитектуры» — зависит от принятых в конкретной организации подходов по организации ИТ-процессов и может стать темой для отдельной дискуссии.
Как бы то ни было, у Заказчика есть, прежде всего, некая потребность, которую ему нужно «закрыть». И у него также могут быть свои идеи и свое «видение» на этот счет, которые ему тоже может быть интересно воплотить.

Например, работая в одном банке, я получила такой заказ – «… а также хотелось бы, чтобы архитектура хранилища была такова, чтобы хранилище исполняло как оперативную, так и аналитическую функцию… короче – нужно хранилище real time!»
Это меня немного озадачило, т.к. это довольно нетипичное и трудновыполнимое требование для систем подобного класса, но как говорится, задача поставлена – надо выполнять. В результате возникла концепция, немного отличавшаяся от первоначальной – не “real time”, а “just-in-time” (идея была заимствована от знаменитого принципа организации производства в компании «Тойота» — «точно во время»). Таким образом, изначальное требование было несколько смягчено и более реалистично с точки зрения технического воплощения, а Заказчик при этом остался удовлетворен тем, как было учтено его изначальное «видение».

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

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

Заказчик может себе позволить жить сегодняшним днем, всевозможными «квиквинами», увлекаться то одной супер-инновацией, то другой, быть захваченным тенденциями и модными трендами, которые так умело представляют технические маркетологи на всевозможных конференциях и событиях от вендоров ИТ-индустрии.
Архитектор же, оставаясь профессионалом «с холодным носом» должен уметь смотреть на 3, 5, 10 шагов вперед. И более того – уметь переключать взгляд своего клиента в будущее. Пытаясь прийти к совместному пониманию, к совместной картине реальности, к которой хотелось бы прийти в обозримый период, которой хотелось бы следовать и вкладывать усилия по ее воплощению.

Архитектура – это про будущее…

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

Автор: verlena

Источник