что нужно изучать архитектуру
13 советов начинающим архитекторам от выпускника Архитекторов.рф
Когда молодому архитектору открывать своё бюро? Можно ли стать миллионером в этой сфере? Где интереснее работать — в Москве или в регионах? Strelka Mag посмотрел лекцию архитектора и выпускника программы Архитекторы.рф Никиты Маликова и подготовил на её основе 13 советов для тех, кто только начинает карьеру.
Не делайте ставку на университет. Я считаю образование архитектора одним из основополагающих. Если вы получите такую специализацию, у вас будет большой выбор, куда развиваться дальше. Но если говорить об университетах, то образование архитектора в России везде одинаковое. Не думайте, что там вас научат быть богом своего дела. В вузе вы получите 5–10 процентов от того, что должны знать на самом деле.
Займитесь самообразованием. Главная фишка архитектора — это постоянное самообразование. Например, самая дорогая вещь в моей квартире — книги. За десять лет я потратил на них почти миллион рублей. Мир постоянно меняется: в университете вас учат азам, но дальше — или параллельно с учёбой — вы должны развиваться сами.
Путешествуйте. Архитектор должен много путешествовать. Было время, когда я куда-нибудь ездил каждые выходные. Я прожил так полтора года. Посетил под сотню стран мира и побывал во всех городах России с населением более 300 тысяч человек. Всю зарплату, которую я получал, я скидывал на поездки, чтобы посмотреть, как и что строится в мире.
Не идите в архитектуру ради денег. Многие идут в эту специальность, думая, что станут богатыми. Это миф. Если вы хотите стать богатыми, советую, например, открыть франшизу по продаже шаурмы. Шаурму будут есть всегда, а про архитектуру нельзя сказать того же. Вы навсегда останетесь средним классом. Да, однажды вы сможете купить себе дом, вы сможете содержать семью и жить в комфорте. Но стать миллионером, работая в архитектуре, нельзя.
Не открывайте своё бюро сразу после получения диплома. Я плохо отношусь к молодым архитекторам, которые сразу после вуза открывают своё бюро и начинают рисовать кучу каких-то концепций. Да, вы научились рисовать качественные рендеры и оформлять чертежи. Научились придумывать идею. Но без опыта, без стажировки и без работы на стройках в адских условиях молодой архитектор никогда не научится понимать, что такое узлы, что такое экономика, что такое ограничения, обременения, согласования и так далее.
И не просите большую зарплату. Сейчас есть тренд: многие после окончания вуза думают, что им сразу начнут платить солидные деньги. Мы постоянно объявляем набор архитекторов. Приходит человек: «Я только окончил вуз, вот моё портфолио, я где-то полгода стажировался, хочу получать 150 тысяч». На что мы говорим: «До свидания». Невозможно столько зарабатывать сразу после диплома.
Устройтесь в крупную компанию. Считаю оптимальным путь, когда после вуза ты устраиваешься в крупную компанию и набираешься опыта. Это минимум три-четыре года, а желательно пять.
Наберитесь терпения. Многие уходят из профессии со словами «Почему моя соседка-официантка зарабатывает больше?» Поймите, ставка профессии официанта стабильна. У начинающего архитектора она ниже. Но архитектор растёт, а официант остаётся на месте. Архитектор — это рост, который редко останавливается.
Приготовьтесь, что настоящая карьера начнётся через пять лет. В среднем через пять лет после выпуска из вуза молодой архитектор должен достигнуть звания ведущего архитектора. И это можно назвать началом его карьерного пути. Особо талантливые могут через пять лет получить статус главного архитектора проекта, если у них есть склонность к управлению и решению кризисных ситуаций.
Научитесь переносить стресс. Ещё одна причина, по которой многие уходят из профессии, — это стресс. Архитекторы должны обладать нереальной стрессоустойчивостью и харизмой, чтобы всё пережить. Они должны легко относиться к кризисам, странным и страшным ситуациям. В вашей жизни их будет много. Есть очень попсовая поговорка: проблема — это не обстоятельство, а то, что мы думаем об этом обстоятельстве. Все проблемы находятся в голове, и архитектору нужно научиться жить с ними.
Не бойтесь работать в регионах. Девелоперы в регионах в разы охотнее идут на эксперименты. Если они увидят выгоду в вашем безбашенном решении, то с радостью возьмут его в работу. В Москве это практически невозможно, за исключением единичных топовых проектов. А зарплата хорошего регионального архитектора, у которого за спиной десять лет опыта, легко приравнивается к зарплате московского.
Будьте оптимистами. Есть формула, которую мы вывели на программе Архитекторы.рф: профессионализм и оптимизм. Это то, что вы должны всегда соблюдать в жизни. Можно сказать, что это soft и hard.
Учитесь мечтать. У меня есть хороший друг, Стас Горшунов, он придумал словосочетание Pinterest-архитектура. Это значит, что мы изучаем чужие работы и бессознательно их копируем. Мы разучились мечтать, придумывать что-то невероятное. И одна из главных задач архитекторов будущего — научиться мечтать, не ограничивая себя ничем. Это сложное упражнение, но вы с этим справитесь, если начнёте поглощать работы других мечтателей. Даже научно-фантастические фильмы для начала вполне подойдут. Изучайте работы современных мечтателей или мечтателей тысячелетней давности. Знаете, как я люблю мечтать? Я надеваю наушники и иду пешком. Включаю свою музыку, а в моей голове возникают картинки, как будто что-то происходит в кино. Как будто моя мечта — это фильм, и я смотрю какой-то сценарий. Так я визуализирую свои мечты. Я думал, что я сумасшедший, но недавно познакомился с девелопером, который сказал, что мечтает точно так же. И я понял, что нас уже двое. Может быть, мы найдем ещё кого-то, кто мечтает так же.
Записки правдивого архитектора: просто о самом главном (Ч.1)
Все нижеизложенное является исключительно частным мнением автора, не имеющим отношения к какому-либо работодателю либо вендору.
«Хмм… правдивого архитектора… А что, такие бывают? – спросите вы и подумаете. — Врет, поди! Сейчас будет нам рассказывать очередную концепцию „бла-бла-бла.2.0“. Знаем, плавали, видали мы „витающих в небесах архитекторов“ и их умозрительные конструкции».
И будете правы: нормальный «пацанский» архитектор — человек очень занятой, и времени писать статьи у него, как правило, нет… Но! Бывает, что настает момент – и желание человека поделиться опытом, рассказать о своих удачах и сложностях миру настолько высоко, что и время находится, и присущий нашему брату-технарю страх публичных высказываний отступает. К тому же коллеги по цеху давно призывали меня начать подобную деятельность.
Стартовать я решила с темы несколько общего характера – ИТ-архитектуры в целом. Почему бы сразу не перейти непосредственно к деталям, которые наиболее занимают читателей технических блогов?
Ответ прост: уж больно много вопросов, трактовок и кривотолков возникают вокруг работы и задач архитекторов. И чтобы двигаться дальше, нужно выстроить некую «общую систему координат» — некую отправную точку.
За время моей работы сложилось некое «видение» происходящего, которым хотелось бы поделиться и обсудить с коллегами.
Что такое архитектура?
Итак, начнем «от печки» — попробуем дать определение этому понятию.
Не только архитекторы, но и древние философы обращали внимание на терминологию в своих беседах с досточтимыми правителями государств: 
«Если имя неправильно (не соответствует сущности), то слово противоречит делу, а когда слово противоречит делу, то дело не будет исполнено, а если дело не будет исполнено, то церемонии и музыка не будут процветать, а если церемонии и музыка не будут процветать, то наказания не будут правильны, а когда наказания будут извращены, то народ не будет знать, как ему вести себя. Поэтому для благородного мужа необходимо, чтобы он непременно [мог назвать правильные имена вещей с тем, чтобы] сказанное исполнить и чтобы в словах его не было ничего бесчестного (недобросовестного)»
/Конфуций «Суждения и беседы»/
И все-таки я не стану приводить все возможные, замечательные по своей полноте, оригинальности и глубоким смыслам, определения термина «архитектура». Да и нет такой задачи — дать идеальное определение (если это вообще возможно). Главное – это понять суть предмета.
А знаете… я вообще не стану приводить определение. По крайней мере, прямо сейчас. Сделаю это позже.
Даже в такой строгой науке, как математика, как говаривал мой педагог из универа, век идеальных определений давно прошел:
«Не помнишь определение из учебника – и не надо. Попробуй пойти от примеров – и таким образом выстроить понятие».
Итак, Архитектура… Да, именно подобные картинки помещаются частенько на титульный лист архитектурной ИТ-концепции и становятся символом («логотипом») архитектурных подразделений крупных компаний.
Конечно, первое, что приходит на ум – это связь с известной всем областью строительства. Архитектура зданий, сооружений, городов – сфера хорошо известная и имеющая давнюю историю.
Справедлива ли аналогия?
Безусловно! Более чем!
Известны целые исследования на эту тему – например, статья Пата Хелланда «Метрополис».
Абсолютно уместной выглядит аналогия: для того, чтобы построение ИТ-систем и комплексов завершалось успешно – нам так же, как и в строительстве, необходимо задумываться и решать этот набор архитектурных вопросов – прежде, чем бросаться «кодить» или «фигачить».
И отталкиваться при этом надо… Правильно – от назначения.
«Вижу цель – не вижу препятствий» или Что такое целевая архитектура?
Есть такая известная во всех крупных компаниях тема – “целевая архитектура”, мифическая и таинственная, почти как любовь: “Все о ней говорят, но мало кто ее видел” /Ларошфуко/
Стало быть, целевая архитектура должна ответить, прежде всего, на вопрос – зачем мы это делаем. Т.е. она обозначает цель, смысл нашей деятельности. И лишь затем мы задумываемся и решаем — каким образом мы будем этого достигать, за счет каких технологий, на каких платформах.
Прежде чем бросаться отвечать на вопрос «как» (делать, внедрять систему, платформу и т.д.) убедитесь, что ответили на вопрос «зачем».
Все просто! И если этого простого (и вроде бы очевидного, не так ли?) шага не сделать, а броситься бегом строить схемы и кодить, кодить, кодить… то есть большой шанс, что этот труд потом улетит в корзину! И в результате посетит и вас, и вашу команду, и ваших заказчиков великая печаль. Задавайте себе этот вопрос не в конце, а вначале своего “забега”.
Как задавать подобные вопросы? Когда и при каких обстоятельствах?
Сформулируем более строго: в рамках каких процессов, кто и когда ставит подобные вопросы, а также кто обязан найти на них ответы, понятные всем участникам.
Четко напрашивается, по крайней мере, один вывод: этими вопросами необходимо озадачиться до точки старта проекта. И даже до момента его инициации. “Но как же так?” – может возникнуть вопрос: “Мы же уже давно привыкли, что вся деятельность ИТ осуществляется в рамках проектов, а в случае гибких методов – в рамках спринтов”.
Вот тут начинается интересное… Послушаем, что говорят на эту тему “ведущие собаководы” ИТ-отрасли — т.е. организации, создающие и распространяющие разного рода стандарты и референсные практики.
Так, OpenGroup на этот счет выпустила недавно концепцию IT4IT. Операционная модель ИТ, которая там представлена, включает в себя набор четырех базовых «цепочек создания ценностей» (VAD). Одна из них – “Strategy to portfolio”, в рамках которого и формируется “портфель проектов”, отталкиваясь от того, что мы хотим видеть (целевое видение) и от ситуации as-is (текущая архитектура). Таким образом, через ИТ-стратегию и портфель проектов выстраивается мостик к нашей желаемой «картинке будущего».
/Самое время спросить себя о том, а как у нас в компании принято формировать «портфель проектов»? Как порождаются проекты? На каком этапе к этому процессу подключают архитекторов? Кто принимает решение о запуске проекта? /
Таким образом, правильным выглядит такой путь:
Сперва целевая архитектура… Точнее, сперва бизнес-стратегия, потом целевая архитектура, которая ее поддерживает, далее — стратегия ИТ, которая отражает переход от текущего состояния к целевой, и, наконец, в соответствие со ИТ-стратегией – формирование портфеля проектов.
Вот почему архитекторы на предприятии так упорно говорят о целевой, о необходимости соответствия проектов ее руслу, о необходимости фиксации отклонений (временных и обходных решений) и т.д. Это их прямая обязанность. Это их работа. И это их ответственность. И для них важно, чтобы разговоры об архитектуре не носили бесконечный характер, а завершались вполне определенным delivery – и определенными (зафиксированными решениями).
Часто ли так происходит?
Да нет, конечно… В нашу стройную систему вмешивается господин Хаос. Точнее люди, которые сами его создают, осознанно или неосознанно. Однако выбирать не приходится – и нам тоже надо как-то существовать в предлагаемых жизнью обстоятельствах – неопределенности, несогласованности, неразберихи и т.д.
Попробуем разобраться, как все происходит, и что с этим можно сделать.
О целевой архитектуре (как и о любви) можно говорить бесконечно… И поэтому, важно зафиксировать некое видение – получить «картинку будущего». Либо несколько вариантов – несколько «картинок».
Почему важно фиксировать? Казалось бы, очевидный вопрос, но как ни странно, много копьев ломается вокруг этого.
Потому как – целевая архитектура – это наша «опора из будущего». Представьте – какой возникнет хаос в нашем портфеле проектов, если она все время будет меняться?
Кто занимается подобной проработкой и отвечает за качество результата? Конечно, ИТ-архитектор – это его зона творчества, влияния и ответственности. При этом он общается с большим количеством людей, собирает и обрабатывает множество информации, изучает существующие аналоги, что-то пробует. И наконец, предлагает некое целостное решение – архитектурную концепцию. Она и представляется на дальнейшее обсуждение и утверждение как целевая архитектура – сперва в очень общем плане – как концепция или видение.
Когда целевое видение появилось, нужно постараться сделать так, чтобы все влиятельные лица (их принято называть «стейкхолдерами») увидели в ней некую ценность для себя и пришли к согласию относительно нее. Таким образом, критерием останова этого «увлекательного занятия» по обсуждению архитектурных концепций будет сокращение замечаний от принимающих решения людей до некого допустимого минимума.
Как и в любом споре, в процессе архитектурных дебатов людей частенько захлестывают эмоции. Что нам важно? Важно с одной стороны, не упустить какого-либо ценного замечания, возможности или потребности. А с другой стороны – направить процесс в конструктивное русло. Т.е. необходимо все суждения переводить в конкретику. Иными словами, требовать обоснования – как от докладчика, представившего вариант архитектуры на рассмотрение, так и от вопрошающего. Уровень «нравится – не нравится» — не лучший способ выстроить подобный процесс, т.к. он слабо результативен.
Хорошим способом является подход, в процессе которого некое предлагаемое решение «проверяется на устойчивость» — вопросы из серии «что будет если…». Взгляд на 360 вокруг этой темы.
Для упорядочения деятельности по принятию подобных коллегиальных решений в крупных компаниях используют практику «архитектурных комитетов». К участию в них привлекаются люди, которых это в той или иной степени коснется – от бизнеса до ответственных за ИТ-инфраструктуру и сопровождение систем. И концепции проходят утверждение там. Далеко не всегда этот процесс на практике выглядит оптимально и результативно. Но других вариантов пока не придумали.
Есть примеры лучших организационных практик – о том, как выстраивать архитектурные процессы, когда и что выносить на коллегиальные обсуждения на комитетах, как подавать и обрабатывать замечания и т.д. И существуют компании, где подобные процессы воплощены в жизнь. Но даже лучшие референсные практики работать не будут, если у людей нет изначального настроя договориться, а в компании не поддерживается атмосфера взаимного уважения и доверия друг к другу.
Здесь может возникнуть вопрос, что делать, если действительно такого настроя в данный момент не прослеживается? Можно ли его поменять?
Во-первых, необходимо увидеть и осознать проблему, приостановить дискуссию непосредственно по теме встречи, т.к. когда люди «сели на эмоции» уровень аргументации, логических доводов перестает работать.
Второй шаг – постараться увидеть позитивное намерение человека, который возражает, как нам может казаться, весьма странно – например, переводит фокус внимания к другой больной для него теме, уводит в сторону и т.п. И увидеть свою собственную приверженность, если вас это, в свою очередь, начинает раздражать. Если мы вовремя «поймали момент», и страсти еще не накались, успели «нажать на паузу», осознать и мысленно сформулировать это, то нас уже сложнее будет «выцепить на эмоцию» — уже хорошо.
Третий шаг – «возвращаем» человеку его же намерение, но в позитивной формулировке. Таким образом, ему не просто сказали, что «я тебя слышу», а его реально услышали и дали обратную связь. Хорошо бы это также записать и пообещать вернуться к этому важному и острому вопросу позже. И попросить разрешения продолжить встречу.
Острота спадает, конструктивный настрой остается.
Конечно, это не так просто. Легко написать — трудно сделать. Нужен опыт и тренировка в коммуникациях и переговорах. Эта тема весьма обширна, и раскрыть ее здесь не получится, только слегка наметить и создать уверенность, что такие подходы точно есть, они рабочие, и при желании их можно найти, изучить и проработать на практике (лучше с помощью опытного наставника).
Словом, мы приходим к выводам, что архитектурная практика – это фактически часть корпоративной культуры, модель принятия решений, общий стиль существования организации и взаимодействия сотрудников внутри нее.
Иными словами, уровень управления ИТ-архитектурой и стратегией – одна из составляющих уровня зрелости компании в целом, которая показывает ее способность к устойчивости и развитию.
Замечу, что «зрелость» по отношению к компании не определяется ее размером или ее возрастом. Бывают довольно крупные компании, которые не отличаются высоким уровнем зрелости: т.е. не стремятся «понять себя» — свой бизнес, своих сотрудников, свои цели. А стратегические инициативы часто носят формальный характер.
В то время как есть стартапы, в которых люди довольно быстро приходят к выводу, что например, одного классного кодинга (если говорить про ИТ-сферу) не достаточно – необходима некая организующая и направляющая сила.
И тому есть реальный примеры. Недавно моего друга-архитектора пригласили поучаствовать в подобном проекте, в котором уже работают хорошие разработчики, работают с драйвом и интересом, на новых технологиях и т.п. И при этом говорят: «как-то странно выходит – кодим-кодим, но как-то… не понятно, к какому результату мы движемся».
Иными словами, компания может на раннем этапе прийти к достаточно высокому уровню зрелости, что повышает ее шансы быть успешной. А, кроме того, и возможно, даже более важно – повышает уровень удовольствия работать в такой компании.
Сейчас много пишут о том, что банкам грозит конкуренция с ИТ-компаниями. И руководители банков начинают спешно перестраивать практики управления под ИТ – внедряют гибкие методы, покупают ИТ-стартапы и т.д. Но это их не сделает ИТ-компаниями. Почему? Потому что не будут в банках работать люди, которые работают в google или amazon. Это не «их формат». И дело тут не в формальных методах управления разработкой и ведения проектов. Сравните подходы к условиям работы, взаимоотношениям в этих компаниях, способам ведения бизнеса и т.д. В чем разница? Это компании разной культуры, разного «способа жизни». Банк – не ИТ-компания, и никогда ей не будет. (Также как и ИТ-компания никогда не будет банком). Так почему бы банкам… не оставаться банками, исследуя и развивая свои сильные качества? (А они у них, бесспорно, есть, в т.ч. и в ИТ.) Вместо того, чтобы бросаться из крайности – в крайность: то передаем ИТ на аутсорсинг как непрофильную обеспечивающую деятельность, то готовимся к конкуренции с ИТ-компаниями.
И это имеет прямое отношение к вопросу зрелости.
Зрелая компания, какого бы размера, возраста, уровня капитала, географии она не была, к какой бы отрасли она не относилась – знает «себя», видит «свое будущее», понимает свой бизнес, слышит своих сотрудников. И стремится найти и выстроить свой путь развития, а не слепо копирует и примеряет на себя чей-то чужой…
Вспоминая сказку про «Золушку» — как бы ни хотелось выйти замуж за принца, не стоит пытаться отрезать себе пятку, пытаясь влезть в чужую хрустальную туфельку.
У каждой компании свой талант, своя тема. Осознанный подход к развитию архитектуры учитывает специфику компании, задачи, проекта, их уникальность.
Архитектурные стандарты и фреймворки
Теперь настало время обратиться к стандартам. И следуя, заветам мудрого Конфуция, дать ясные определения интересующих нас понятий, чтобы «церемония и музыка» процветали, а «сказанное» было исполнено.
По части ИТ-архитектуры существует несколько детально проработанных стандартов.
Прежде всего, это ISO/IEC 42010: 2007, где можно обнаружить следующее определение:
Архитектура — это фундаментальные концепции или свойства системы, состоящей из элементов, связей между ними и внешним окружением, а также принципы ее разработки и развития.
Почему я стала говорить об определениях в контексте фреймворков? Что означает само по себе понятие «фреймворк»?
Фреймворк определяет методологию решения задачи определенного класса. От слова «метод» — повторяемый подход, применение которого приводит к предсказуемым результатам.
В чем их ценность фреймворков? В том, что однажды найденное, быть может, случайно, удачное решение осознается и применяется далее в подобных ситуациях. При этом фреймворк не диктует решение досконально и полностью, оставляя, так называемые, «точки расширения».
Неслучайно требование «адаптивности» все чаще звучит по отношению и ИТ организации. Порой это приводит к неоправданно завышенным ожиданиям – получить возможность решения совершенно разных задач «из одной коробки». Это не всегда оправданно. Есть более эффективный путь – использовать компонентную архитектуру, не перегружая инструменты и технологии несвойственным и избыточным для них функционалом. Такой вариант гораздо прозрачнее и устойчивее в применении. Но он также требует и затрат – уже не достаточно лишь узкого знания некой одной системы – требуется объединить множество систем, интегрировать в единый ИТ-ландшафт.
И роль ИТ-архитектора, его задача – как раз помочь в этом процессе. Он не принимает решений единолично, он собирает и представляет информацию таким образом, чтобы то было понятно многим людям в компании – от бизнеса до инженеров – т.е. подготавливает почву для принятия коллегиального решения. Это не значит, что он не должен обладать технологическими знаниями – как раз наоборот – практика работы с технологиями – один из ключевых аспектов его деятельности. Но как будет показано далее, далеко не единственный.
Итак, ключевой смысл архитектуры и ключевые задачи архитекторов – это определение состава компонентов, их ответственности и взаимосвязи, отталкиваясь от конкретной прикладной задачи, которую мы решаем.
На мой взгляд, это вполне достойная миссия, требующая различных фокусов внимания и разносторонних компетенций – как технологических и системных, так и коммуникативных и организационных.
Завершая тему с определениями, приведу еще одно, от компании Oracle, которое, как мне показалось, очень хорошо отражает суть и глубину предмета:
Архитектура – метод и организующий принцип, которые согласуют функциональные задачи и стратегии бизнеса с ИТ-стратегией и планом исполнения.
Кто наш заказчик и какие у него могут быть желания, высказанные и невысказанные
Как и у любого исполнителя, решающего поставленную кем-то задачу, у архитектора есть… правильно – тот, кто ее поставил – т.е. Заказчик! Кто может быть таким заказчиком и как может выглядеть «процесс заказа архитектуры» — зависит от принятых в конкретной организации подходов по организации ИТ-процессов и может стать темой для отдельной дискуссии.
Как бы то ни было, у Заказчика есть, прежде всего, некая потребность, которую ему нужно «закрыть». И у него также могут быть свои идеи и свое «видение» на этот счет, которые ему тоже может быть интересно воплотить.
Например, работая в одном банке, я получила такой заказ – «… а также хотелось бы, чтобы архитектура хранилища была такова, чтобы хранилище исполняло как оперативную, так и аналитическую функцию… короче – нужно хранилище real time!»
Это меня немного озадачило, т.к. это довольно нетипичное и трудновыполнимое требование для систем подобного класса, но как говорится, задача поставлена – надо выполнять. В результате возникла концепция, немного отличавшаяся от первоначальной – не “real time”, а “just-in-time” (идея была заимствована от знаменитого принципа организации производства в компании «Тойота» — «точно во время»). Таким образом, изначальное требование было несколько смягчено и более реалистично с точки зрения технического воплощения, а Заказчик при этом остался удовлетворен тем, как было учтено его изначальное «видение».
Таким образом, какой бы формальной и строгой ни выглядела наша сфера деятельности, нам необходимо знать и даже «чувствовать» Заказчика, его желания и потребности, его опасения и даже некий негативный опыт. И нам нужно уметь представить концепцию решения таким образом, чтобы ему захотелось «купить» данный продукт – т.е. чтобы представленная «картинка будущего» в конце концов (быть может после ряда обсуждений и дискуссий) совпала с его ожиданиями – и ему захотелось двигаться, вкладываться в этом направлении.
Необходимо отметить еще одну, на мой взгляд, немаловажную деталь. Помимо требований, высказываемых Заказчиком в явном виде, всегда есть набор «умолчательных» требований — те, что подразумеваются, но в явном виде не говорятся.
Профессионал всегда держит в поле зрения всю свою область, он контролирует ситуацию, он знает больше и глубже об этом, чем его клиент. Иначе клиент бы к нему не обращался. И он должен всегда помнить, что он профессионал, и у него есть ответственность.
Так, вышедший недавно на экраны фильм «Эверест» очень конкретно показывает, к каким трагичным последствиям могут привести ситуации, когда профи слепо следует «хотелкам» клиента.
Здесь всплывает еще один «заезженный» термин – клиентооринтированность.
Да, безусловно, знать, понимать, уважать внутреннего клиента необходимо. Но ответственность за результат всегда несет исполнитель. И более профессионально – отказать клиенту в чем-то, даже пойти на конфликт, нежели позволить случиться событиям, последствия которых могут быть фатальными.
И снова обратимся к области строительства и ремонта, всем знакомой и наглядной. Любой уважающий себя специалист – сантехник или электрик – не станет ни под каким-бы то ни было давлением со стороны клиента реализовывать проект с нарушениями технических норм. И приведет четкие аргументы.
Так почему же в ИТ должно быть иначе? Возможно, последствия будут не так драматичны. Но если мы можем с достаточной уверенностью сказать о рисках – нужно о них сказать. Это будет честно и уважительно по отношению к своему клиенту-заказчику.
Заказчик может себе позволить жить сегодняшним днем, всевозможными «квиквинами», увлекаться то одной супер-инновацией, то другой, быть захваченным тенденциями и модными трендами, которые так умело представляют технические маркетологи на всевозможных конференциях и событиях от вендоров ИТ-индустрии.
Архитектор же, оставаясь профессионалом «с холодным носом» должен уметь смотреть на 3, 5, 10 шагов вперед. И более того – уметь переключать взгляд своего клиента в будущее. Пытаясь прийти к совместному пониманию, к совместной картине реальности, к которой хотелось бы прийти в обозримый период, которой хотелось бы следовать и вкладывать усилия по ее воплощению.
Архитектура – это про будущее…
Именно в этом контексте далее во 2й части статьи я поставлю странный вопрос: «что такое хорошая архитектура?» Впрочем, он не выглядит таким уж странным с учетом всего вышесказанного. Т.к. он акцентирует внимание на неких «скучных» вещах, которые, однако, уберегут нашу систему, нашего клиента от нежелательных сценариев дальнейшего развития.