Здравствуйте, Ароан, Вы писали:
А>Скажем так, проектировщик дает на выход модель классов, которые остается написать, а архитектор, как я понимаю — архитектуру. Чем собственно эта архитектура отличается от моделей классов? Их чего состоит эта самая архитектура? Это просто более абстрактная модель классов?
Архитектор в принципе такими вещами не занимается, как модель классов. Самый заезженный пример наверное приведу, но ничего другого пока в голову не приходит:
Строится здание. Архитектор выбирает место для здания, проектирует внешний вид здания, его функциональность, насколько оно вписывается в существующую инфраструктуру района, какие дополнительные объекты надо построить, какие переделать (например, построить новую школу, старую снести и на ее месте построить больницу) Выясняет перед тем как строить, не собираются ли этот район сносить через полгода, все ли необходимые коммуникации проведены, нет ли поблизости другого здания со схожей функциональностью (типа на хрена нам 2 школы вместе, когда в районе всего 100 учеников) и.т.д. и.т.п.
Короче говоря, отвечает за то чтобы это здание органично вписывалось в инфраструктуру района. При этом его функции выходят за пределы строительства одно единственного здания, он отвечает за целый район, за то чтобы все работало четко и слаженно.
А проектировщик проектирует уже непосредственно здание, что за чем строить и каким образом, проектировать коммуникации в здании, ну там типа водопровод, канализацию и телефон, и при этом постараться чтобы одно не впадало в другое.
Если добро всегда побеждает зло, значит кто победил — тот и добрый.
Здравствуйте, Maxim S. Shatskih, Вы писали:
R>>Пример и видение 75-го года от Брукса, интересны мнения: сильно ли концептуально устарело или нет?[q]Аристократия и демократия
MSS>Околесица ИМХО написана Бруксом.
MSS>Перепутаны архитектор и аналитик требований ("постановщик задачи").
Никакой околесицы и путаницы нет. Это у нас, в русском сознании, архитектором называют человека, который придумывает внутреннюю структуру программы.
А на западе под термином Software Architect понимают человека, который придумывает внешнее поведение системы. Именно это поведение описывает решение задачи, сформулированной пользователем.
У нас традиционно этим вообще никто не занимается. Большая часть софта разрабатывается, полностью минуя стадию выбора подходящего поведения — от требования "Мне нужно отслеживать статусы сепулек" мы мгновенно, не думая, переходим к "экран №123412: список сепулек пользователя", а архитектор занимается разработкой фреймворка для отображения списков и деревьев. Более того, если спросить "кто вас просил делать этот чудовищный список сепулек с постраничной навигацией" любой разработчик мгновенно ответит: "пользователь!".
По западным привычкам, архитектор закончит свою работу на том, что придумает то, как система помогает пользователю отслеживать статус сепулек. Дальше он отдаст спецификацию этого поведения разработчику, и тот заданное поведение реализует. Если разработчик не в состоянии реализовать "список с постраничной навигацией", то его надо уволить. Если у нас часто возникают задачи "сделать список с постраничной навигацией", то нужно купить библиотеку для этих списков, или, в крайнем случае, попросить старшего разработчика один раз ее написать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
...
UIE>Короче говоря, отвечает за то чтобы это здание органично вписывалось в инфраструктуру района. При этом его функции выходят за пределы строительства одно единственного здания, он отвечает за целый район, за то чтобы все работало четко и слаженно.
UIE>А проектировщик проектирует уже непосредственно здание, что за чем строить и каким образом, проектировать коммуникации в здании, ну там типа водопровод, канализацию и телефон, и при этом постараться чтобы одно не впадало в другое.
По моему идея с аналогией в области строительства вполне удачна!
Однако уважаемый UnIc0dE ошибается, когда пытается описать, как это разделение (Архитектор vs Проектировщик) выглядит в строительстве.
На самом деле архитектор проблемами района, сноса школ и строительства новых зданий конечно не занимается. В его задачу входит создать проект здания, включая внешний вид, внутреннее устройство: расположение комнат, туалетов, лестничных клеток, коммуникаций и.т.п. Архитектор получает на входе требования от заказчика и должен в результате выдать общий проект здания, так чтобы оно максимально соответствовало требованиям заказчика и вписывалось в окружающую застройку, естественно.
Теперь в чём заключается работа проектировщика (в строительстве их также называют конструкторами).
Проектировщики (конструктора) берут проект здания, предоставленный архитектором, и смотрят, насколько архитектурные решения можно реализовать на практике. Т.е. вся разница между архитектором и проектировщиком в том, что архитектор мало задумывается о том, можно реально построить то что он придумает или нельзя, и какие могут быть трудности при реализации проекта на практике. Архитектор думает об устройстве здания в основном в плане удобства его эксплуатации, а также о красивом дизайне, в то время как проектировщика (конструктора) такие моменты как красота и функциональность здания для людей вообще не интересует. Всё, чем занимается проектировщик в строительстве это то, что он решает, как конкретно, в реальных конструкциях, с реальными материалами, узлами и сечениями и.т.п. реализовать конструкции, задуманные архитектором.
Реально архитектор и проектировщик работают в паре. Какие то слишком сложные и трудоёмкие моменты проектировщик согласовывает с архитектором, в том плане можно от этого избавиться или нет, и тогда архитектор решает, нисколько важен данный элемент для здания в целом. Бывает конечно и такое, когда архитектурные элементы просто невозможно реализовать на практике, и тогда проектировщик сообщает об этом архитектору и тот должен придумать что то другое.
Это из моего личного опыта в строительстве (по образованию я инженер-строитель, но вот уже два года работаю программистом).
По моему аналогия с программированием довольно ясная, так то не буду тратить время на её описание.
P.S.
Хочу уточнить, что конечно же и архитектор, в процессе, когда он разрабатывает свой архитектурный проект, тоже задумывается как это может быть реализовано и может ли вообще. Естественно, что архитектор — это не художник авангардист, который вообще никак не соотносит себя с реальностью. Конечно же хороший архитектор заранее предвидит все трудности, которые могут возникнуть на стадии реализации и отчасти соотносит свой проект с ними (заранее). Просто это не его основная задача. Задача архитектора — разработать проект здания, который прежде всего отвечает требованиям заказчика по функциональности и внешнему виду, а потом согласовать его с проектировщиком.
Здравствуйте, Sinclair, Вы писали:
S>А на западе под термином Software Architect понимают человека, который придумывает внешнее поведение системы. Именно это поведение описывает решение задачи, сформулированной пользователем.
Чем принципиально отличается архитектор от проектировщика?
Если можно на конкретном примере, а то читаю книжку по RUP и не могу провести разграничительную линию.
Здравствуйте, Ароан, Вы писали:
А>Чем принципиально отличается архитектор от проектировщика?
На мой взгляд, ничем. Более существенный вопрос: Чем отличается Архитектор от обычного Программиста? Что делает Архитектор, чего обычный Программист сделать не в состоянии? В чем заключается разница в квалификациях?
Частично — помимо шаблонного ("Архитектор видит всю архитектуру системы в целом") — я знаю.
КЛ>На мой взгляд, ничем. Более существенный вопрос: Чем отличается Архитектор от обычного Программиста? Что делает Архитектор, чего обычный Программист сделать не в состоянии? В чем заключается разница в квалификациях?
Архитектор — это тот же программист по опыту работы, которому более высокое руководство доверило разрабатывать архитектуру системы в целом, т.е. принимать самые важные и самые дорогостоящие технические решения, а в дальнейшем координировать работу обычных девелоперов (а то и команд) в технических вопросах — например, описаний интерфейсов на стыках компонент от разных команд.
Если такая работа требует значительных трат времени, то столь ценного кадра освобождают от рутинной тупой "работы руками" по имплементации в коде простейших фич по четким заданиям.
Вот и все.
В некоторых командах (ИМХО дисфункциональных) с архитектора вообще снимают любое написание кода. Это плохо, ибо поощряет тенденцию отрыва от реального железа, кода и тулов и витание в облаках абстракций. Таковое витание, в свою очередь, приводит, например, к игнорированию конкретных хитрых особенностей платформы и тулов, что в свою очередь может снизить качество продукта до неприемлемо низкого. Ну и abstraction overhead никто не отменял.
По аналогии со строительством: архитектор — человек, несущий общую ответственность за техническую часть проекта. Это некий "технический ПиЭм".
Проектировщик — это не руководящая позиция, а рядовая, т.е. девочка-чертежница. Она умеет чертить в соответствии с нормативами, и в общем знает общие принципы расчета конструкций, кое-где их применяя. Но последнее слово остается не за ней, а за архитектором.
Проектировщики появляются только а) в жестком вотерфолле, где сначала делается вся проектная документация и только потом приступают к коду и б) где архитектор в одиночестве уже не потянет разработку всей этой документации.
R>Пример и видение 75-го года от Брукса, интересны мнения: сильно ли концептуально устарело или нет?[q]Аристократия и демократия
Околесица ИМХО написана Бруксом.
Перепутаны архитектор и аналитик требований ("постановщик задачи").
Представителем пользователя является именно и конкретно аналитик требований. Он привносит пользовательский взгляд на систему, и его функция — сделать так, чтобы этот взгляд таки в системе отражался. Ему при этом в общем плевать на технические нюансы системы.
Архитектор скорее представитель авторов платформы, авторов тулов (в т.ч. синтаксисов языков), и законов физики
Обязанность архитектора — а) обеспечить работоспособность и приемлемую производительность продукта на требуемых платформах б) принять решения об используемых тулах, исходя из сложного баланса трудоемкость/реализация нестандартных фич в) обеспечить, чтобы код мог развиваться в дальнейшем без больших переделок значительное время.
Исполнение этой обязанности требует продумывания всей архитектуры продукта, "крупноблочного" его устройства. Отсюда название "архитектор".
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Архитектор — это тот же программист по опыту работы, которому более высокое руководство доверило разрабатывать архитектуру системы в целом, т.е. принимать самые важные и самые дорогостоящие технические решения, а в дальнейшем координировать работу обычных девелоперов (а то и команд) в технических вопросах — например, описаний интерфейсов на стыках компонент от разных команд.
Если проводить аналогию со строительством, то по Вашему получается что Архитектор == Каменьщик.
Здравствуйте, AndrewVK, Вы писали: AVK>Ну, как показывает википедия, единого мнения нет и на западе. AVK>http://en.wikipedia.org/wiki/Software_Architect
Ну вот так всегда! Мир до этого интернета был простым и непротиворечивым.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ароан, Вы писали:
А>Чем принципиально отличается архитектор от проектировщика? А>Если можно на конкретном примере, а то читаю книжку по RUP и не могу провести разграничительную линию.
Ой боюсь все опять кончится как в ветке обсуждения "Бизнес-аналитик vs Системный аналитик" на форуме "Управление проектами" "Бизнес-аналитик vs Системный аналитик" ...
Скажем так, проектировщик дает на выход модель классов, которые остается написать, а архитектор, как я понимаю — архитектуру. Чем собственно эта архитектура отличается от моделей классов? Их чего состоит эта самая архитектура? Это просто более абстрактная модель классов? Есть какой-то ГОСТ как должна выглядеть архитектура?
B>Ой боюсь все опять кончится как в ветке обсуждения "Бизнес-аналитик vs Системный аналитик" на форуме "Управление проектами" "Бизнес-аналитик vs Системный аналитик" ...
B>Сразу скажите, в каком контексте вопрос ...
Здравствуйте, Ароан, Вы писали:
А>Добрый день.
А>Чем принципиально отличается архитектор от проектировщика? А>Если можно на конкретном примере, а то читаю книжку по RUP и не могу провести разграничительную линию.
А>Спасибо.
Имхо, редко когда появляющиеся различные уровни абстракции.
Архитектор, по идее, должен иметь представление о полной системе и оперировать более глобальными пояниями, чем классы, например — модули .
Проектировщик же и проектирует эти самые модули на более низком уровне.
Хотя на практике, хоть я и занимался (юсь) архитектурой, но всегда, даже для достаточно больших проектов, приходилось заниматься и проектированием классов, интерфейсов, а не только (и может даже — не столько) интерфейсами модулей, выбором архитектурного какого-нить решения.
В маленьких проектах = это вообще малоразличимые понятия.
Здравствуйте, Ароан, Вы писали:
А>Скажем так, проектировщик дает на выход модель классов, которые остается написать, а архитектор, как я понимаю — архитектуру. Чем собственно эта архитектура отличается от моделей классов? Их чего состоит эта самая архитектура? Это просто более абстрактная модель классов? Есть какой-то ГОСТ как должна выглядеть архитектура?
ГОСТ не оперирует понятием "архитектура" как таковым. Так, например в соответствии с ГОСТ 19 серии, на стадиях Эскизный проект и Технический проект создаюется документ "Пояснительная записка", в которой можно описать моменты связанные с архитектурой и дизайном (ГОСТ 19.404-79).
Говоря о ГОСТ 34-й серии ... то на аналогичных стадиях и этапах 4.1. "Разработка предварительных проектных решений по системе и её частям" и 5.1 "Разработка проектных решений по системе и её частям" создаются аналогичный документ "Пояснительная записка", но осмелюсь предположить, что вещи более близкие к архитекртуре выносятся в документ Описание постановки задачи (РД 50-34.698-90)
Здравствуйте, Ароан, Вы писали:
А>Добрый день.
А>Чем принципиально отличается архитектор от проектировщика? А>Если можно на конкретном примере, а то читаю книжку по RUP и не могу провести разграничительную линию.
Архитектор описывает различные взгляды на систему (по RUP их кажется штук 7), а проектировщик (Designer) некоторые из этих взглядов детализирует и превращает в спецификации.
Здравствуйте, UnIc0dE, Вы писали:
UIE>Архитектор в принципе такими вещами не занимается, как модель классов. Самый заезженный пример наверное приведу, но ничего другого пока в голову не приходит:
UIE>Строится здание. Архитектор выбирает место для здания, проектирует внешний вид здания, его функциональность, насколько оно вписывается в существующую инфраструктуру района, какие дополнительные объекты надо построить, какие переделать (например, построить новую школу, старую снести и на ее месте построить больницу) Выясняет перед тем как строить, не собираются ли этот район сносить через полгода, все ли необходимые коммуникации проведены, нет ли поблизости другого здания со схожей функциональностью (типа на хрена нам 2 школы вместе, когда в районе всего 100 учеников) и.т.д. и.т.п. UIE>Короче говоря, отвечает за то чтобы это здание органично вписывалось в инфраструктуру района. При этом его функции выходят за пределы строительства одно единственного здания, он отвечает за целый район, за то чтобы все работало четко и слаженно.
По-моему пример с архитектором не очень.
Нифига архитектор здания не занимается сносом соседних школ и не выясняет перспективы развития микрорайона, тем более не думает о том, подведены ли коммуникации, этим как раз по Вашей терминологии по-моему проектировщик заниматься должен.
А архитектор должен нарисовать дом очень подробно, чтобы проектировщик мог построить его где угодно, хоть рядом со школой, хоть рядом с больницей, лишь бы коммуникации требуемые были.
PS: под "архитектором" и "проектировщиком" тут понимаются реальные строительные архитекторы и проектировщики.
Здравствуйте, Rothmans, Вы писали:
R>PS: под "архитектором" и "проектировщиком" тут понимаются реальные строительные архитекторы и проектировщики.
Моей целью было не рассказать как работают реальные строительные архитекторы и проектировщики, а образно показать разницу между первыми и вторыми в IT.
Если добро всегда побеждает зло, значит кто победил — тот и добрый.
Re[2]: Архитектор vs Проектировщик
От:
Аноним
Дата:
10.03.06 07:47
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Ароан, Вы писали:
А>>Чем принципиально отличается архитектор от проектировщика?
КЛ>На мой взгляд, ничем.
Я бы добавил, что в RUP нет роли проектировщик. Фаза проектирования есть, рабочий процесс проектирования тоже есть, а проектировщиков нет
КЛ>Более существенный вопрос: Чем отличается Архитектор от обычного Программиста? Что делает Архитектор, чего обычный Программист сделать не в состоянии? В чем заключается разница в квалификациях? КЛ>Частично — помимо шаблонного ("Архитектор видит всю архитектуру системы в целом") — я знаю.
Наиболее близко программисту в RUP это роль инженер по компонентам.
Задача архитектора — разработать архитектуру. Он делит систему на подсистемы, определяет интерфейсы между подсистемам, распределяет подсистемы между физическими узлами, выбирает технологии. Т.е. рассматривает систему в целом.Он должен обладать как знаниями предметной области, так и знаниями различных технологий.
Задача инженера по компонентам — проектировать, анализировать, разработатывать компоненты системы (подсистемы, классы). Знания предметной области для этой роли не так важны. Необходимы узкие и глубокие знания конкретных технологий для разработки необходимых компонентов.
И еще. Необходимо различать роли и конкретных людей. Архитектор в RUP может быть как отдельным лицом, так и группой. Т.е. человек на должности разработчика (программист), обладающий необходимым знаниями для разработки архитектуры и осуществляющий ее разработку, в терминах RUP будет называться архитектором.
Здравствуйте, Ароан, Вы писали:
А>Чем принципиально отличается архитектор от проектировщика? А>Если можно на конкретном примере, а то читаю книжку по RUP и не могу провести разграничительную линию.
Пример и видение 75-го года от Брукса, интересны мнения: сильно ли концептуально устарело или нет?
Аристократия и демократия
Концептуальная целостность, в свою очередь, требует, чтобы проект исходил от одного разработчика, или небольшого числа их, действующих согласованно и в унисон.
С другой стороны, напряженность графика требует привлечения большого числа работников. Есть два метода разрешения этой дилеммы. Первый состоит в тщательном разделении труда между архитектурой и исполнением. Второй — новый способ организации бригад программистов-исполнителей, обсуждавшийся в предыдущей главе. Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами. Я лично был свидетелем успешного его применения при создании IBM компьютера Stretch и серии продуктов System/360. Но он не сработал при разработке Operating System/360, поскольку недостаточно применялся.
Под архитектурой системы я понимаю полную и подробную спецификацию интерфейса пользователя. Для компьютера это руководство по программированию. Для компилятора это руководство по языку. Для управляющей программы это руководство по одному или нескольким языкам, используемым для вызова ее функций. Для системы в целом — это набор всех руководств, к которым должен обращаться пользователь при работе.
Архитектор системы, как и архитектор здания, является представителем пользователя. Его задача — использовать все свои профессиональные и технические знания исключительно в интересах пользователя, а не продавца, изготовителя и т.п.2 Архитектура и разработка должны быть тщательно разделены. Как сказал Блау (Blaauw), "архитектура говорит, что должно произойти, а разработка — как сделать, чтобы это произошло". В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и заводной головки. Ребенок, освоивший это архитектуру, с одинаковой легкостью может узнать время и по ручным часам, и по часам на колокольне. Исполнение же и его реализация описывают, что происходит внутри: передача усилий и управление точностью каждым из многих механизмов.
К примеру, в System/360 одна и та же архитектура компьютера совершенно по- разному реализована примерно в девяти моделях. Обратным образом, одна и та же реализация потока данных, памяти и микропрограмм из Model 30 использовалась в разное время в четырех различных архитектурах: System/360, мультиплексном канале с подключением до 224 логически независимых подканалов, селекторном канале и компьютере 1401.
Такие же различия можно проводить в отношении систем программирования. Существует стандарт для Fortran IV. Это архитектура, используемая во многих компиляторах. В рамках этой архитектуры возможны разные реализации: текст в оперативной памяти или компилятор,быстрая или оптимизирующая, синтаксическая или ad hoc Аналогично, любой язык ассемблера или язык управления заданиями допускает многие реализации ассемблера или планировщика.
(прим. ред. И дальше много-много бальзама на душу разработчика обиженного на то, что ему ставит задачу архитектор)
B>Ой боюсь все опять кончится как в ветке обсуждения "Бизнес-аналитик vs Системный аналитик" на форуме "Управление проектами" "Бизнес-аналитик vs Системный аналитик" :-
Сама фраза "системный аналитик" бессмысленна. Она примерно равносильна слову "мозган", и смысла в ней столько же. Ну или слову "специалист".
А раз четкой семантики фраза в себе не несет, то ее применяют по поводу и без повода. Например, так называют архитекторов. Так называют аналитиков требований. Так называют просто толковых программистов.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Околесица ИМХО написана Бруксом.
Да, есть некоторая сумбурность, но по-моему вполне объяснимая (см. ниже).
MSS>Перепутаны архитектор и аналитик требований ("постановщик задачи"). MSS>Представителем пользователя является именно и конкретно аналитик требований. Он привносит пользовательский взгляд на систему, и его функция — сделать так, чтобы этот взгляд таки в системе отражался. Ему при этом в общем плевать на технические нюансы системы.
По-моему, просто Брукс засунул архитектора в "представители пользователя" просто по другому критерию, нежели сейчас обычно понимается, мне показалось, что он говорит о некоторой ответственности архитектора за разрабатываемую систему.
MSS>Исполнение этой обязанности требует продумывания всей архитектуры продукта, "крупноблочного" его устройства. Отсюда название "архитектор".
В то время как программист может дальше носа своего программного компонента ничего и не видеть и заблуждаться по поводу ожиданий клиента (на самом деле, конечно же, посредством бизнес-аналитика и далее системного аналитика), архитектор, кроме прочего, должен смотреть на требования к системе и сводить внутренние проектные движения не в направлении достижения ожиданий бизнес-аналитика к минимуму.
[skipped]
В принципе, все это достаточно хорошо укладывается в "диполь Тыугу" (бизнес-аналитик/постановщик + системный аналитик/архитектор): Диполь Тыугу, или Как преодолеть искажения ИС — то есть все, что вы сказали верно, но Брукс вроде особенно и не противоречит этому, просто недостаточно подробно описал... ну или недостаточно хорошо понимал тогда все это.
R>По-моему, просто Брукс засунул архитектора в "представители пользователя" просто по другому критерию, нежели сейчас обычно понимается, мне показалось, что он говорит о некоторой ответственности архитектора за разрабатываемую систему.
Я вас, вероятно, обрадую, но на самом деле никакой ответственности не лежит ни на ком ну что сделают с архитектором, который провалил проект? уволят? а он новое место найдет. Про рядовых сотрудников я и вовсе не говорю.
Слово "ответственность" тут надо понимать только в контексте "что от кого зависит". Если важнейшие вещи, которые могут принести серьезные проблемы, зависят от низкопоставленного (а потому зачастую малоопытного и туповатого) человека — то это сильно повышает риски, и все это интуитивно всегда понимали: принимать серьезные решения может только зарекомендовавший себя человек.
R>и сводить внутренние проектные движения не в направлении достижения ожиданий бизнес-аналитика к минимуму.
Ну это очевидно. Но архитектор таки представитель платформ, тулов и законов физики, а не пользователя.
R>В принципе, все это достаточно хорошо укладывается в "диполь Тыугу" (бизнес-аналитик/постановщик + системный аналитик/архитектор):
О! Эта пара прекрасно работает, я это с конца 90х знал безо всяких Тыугу.
[skipped]
Это все верно, со всем согласен, только, по-моему, Брукс все же ничему этому особенно не противоречит, а просто говорите несколько о другом.
MSS>О! Эта пара прекрасно работает, я это с конца 90х знал безо всяких Тыугу.
Ну... Э. Х. Тыугу постарее будет.
Здравствуйте, Sinclair, Вы писали:
S>А на западе под термином Software Architect понимают человека, который придумывает внешнее поведение системы. Именно это поведение описывает решение задачи, сформулированной пользователем.
S>У нас традиционно этим вообще никто не занимается. Большая часть софта разрабатывается, полностью минуя стадию выбора подходящего поведения — от требования "Мне нужно отслеживать статусы сепулек" мы мгновенно, не думая, переходим к "экран №123412: список сепулек пользователя", а архитектор занимается разработкой фреймворка для отображения списков и деревьев. Более того, если спросить "кто вас просил делать этот чудовищный список сепулек с постраничной навигацией" любой разработчик мгновенно ответит: "пользователь!".
S>По западным привычкам, архитектор закончит свою работу на том, что придумает то, как система помогает пользователю отслеживать статус сепулек. Дальше он отдаст спецификацию этого поведения разработчику, и тот заданное поведение реализует. Если разработчик не в состоянии реализовать "список с постраничной навигацией", то его надо уволить. Если у нас часто возникают задачи "сделать список с постраничной навигацией", то нужно купить библиотеку для этих списков, или, в крайнем случае, попросить старшего разработчика один раз ее написать.
1. Позвольте узнать на основании чего возникло утверждение про Архитектора и архитектуру как "внешнее поведение" или что вы понимаете под внешним поведением? Какие стандарты или методологии подтверждают эту точку зрения? И было бы здорово если бы вы уточнили, что значит "на западе" ... это в отдельно взятой западной компании или где?
2. Как соотносится ваше утверждение про Software Architect со SWEBOK (http://www.sorlik.ru/swebok/3-2-software_engineering_design.pdf), со стандартом IEEE 1471 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems), а так же с этим http://www.sei.cmu.edu/architecture/published_definitions.html#Modern и с этим http://www.sei.cmu.edu/architecture/what_architects_do.pdf
3. Как вы прокомментируете явное сходство вашего утверждения с тем, что в RUP назывют моделью анализа и/или в AIM функциональной архитектурой?
