Друзья,

понимаю тема сложная, возможна, непрофильная для нашего форума. Потому предлагаю помочь мне в ответе на такой вопрос:

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

Тут следует обратить внимание на то, что выпускники таких специальностей если и получают навыки программирования, то довольно поверхностные и в большей степени в области прикладного программирования, довольно глубоко работе с SQL. В большей степени изучаются разные технологии, в том числе моделирование, работе с информацией и т.п. (довольно близко к прикладной информатике и прикладной экономики)

Например:
знать и понимать, что такое архитектура системы
знать архитектурные стили систем различного масштаба
знать атрибутно-ориентированный метод разработки архитектуры
....

Есть гипотеза: "Если человек не пишет код в течении года, он перестает быть архитектором." Но в этой гипотезе, скорее, имеется ввиду низкоуровневая архитектура.

А вот что нужно знать для высокоуровневой...
* В каких случаях нужно использовать UDDI? А для чего?
* Как версионируется система из десятка компонент? (в частности, по версиям протоколов обмена)
* Почему не стоит хранить в БД ни пароли, ни хеши паролей? И где их хранить?
* Почему автоинкремент идентификаторов must die?
* Во сколько раз увеличивается стоимость разработки при переходе от централизованной БД к распределенке?

Есть гипотеза: "Если человек не пишет код в течении года, он перестает быть архитектором." Но в этой гипотезе, скорее, имеется ввиду низкоуровневая архитектура.

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

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

А вот что нужно знать для высокоуровневой...
* В каких случаях нужно использовать UDDI? А для чего?

http://ru.wikipedia.org/wiki/UDDI/ - т.е. без этого специалист не специалист?

* Как версионируется система из десятка компонент? (в частности, по версиям протоколов обмена)

Если честно не понял, к чему это? Разве версионирование - это не вопрос проектирования и разработки?

* Почему не стоит хранить в БД ни пароли, ни хеши паролей? И где их хранить?

А причем тут архитектура?

* Почему автоинкремент идентификаторов must die?

Опять же причем тут архитектура? Если причем то хотелось бы услышать

* Во сколько раз увеличивается стоимость разработки при переходе от централизованной БД к распределенке?

Единственное, что мне кажется относится к архитектуре, но ответ очень сложный реально. Хотя понятно, что в распределенных системах возрастает сложность

Угу, согласен. Довольно сложно определить, какие вещи относятся к архитектуре, а какие нет. В умах, к несчастью, разруха и хаос.
Определение из википедии "Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними." Выглядит красиво, но совершенно бесполезно.

Я попробовал станцевать с другой стороны:

Сначала определим термин "архитектурная ошибка". Архитектурная ошибка - это реализация в коде, которая обладает следующими качествами:
1. удорожает изменение системы и/или делает невозможным удовлетворение потребностей заинтересованных лиц.
2. стоимость изменения этого решения сильно растет со временем.
Описанием архитектуры назовем такое описание, где возможно совершить архитектурную ошибку.[/i]

Пример. Выбор платформы реализации позволяет допустить архитектурную ошибку. Т.к.:
1. выбор аксесса сильно ограничивает  масштабирование по числу пользователей
2. Смена платформы сильно растет со временем.

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

Угу, согласен. Довольно сложно определить, какие вещи относятся к архитектуре, а какие нет. В умах, к несчастью, разруха и хаос.
Определение из википедии "Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними." Выглядит красиво, но совершенно бесполезно.

Любишь ты такие провокационные заявления.

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

Звучит недурно. А какого соглашения ты от меня ждешь?

ieee 1471 Дает такое определение
фундаментальная организация системы воплощенная через свои компоненты, связи между ними и ее окружением, а также принципы, руководящие ее проектированием и развитием.

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

Каждое из этих понятий естественно можно актуализировать через понятие последствие от ошибки. Очень хорошо.
Как это должно противоречить понятию архитектуры. Мы обсуждает это понятие?

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

Мне не нравится определение ieee 1471. Из него непонятно, что относить к архитектурным решениям.

Рассмотрим решение об [не]использовании UDDI. Архитектурное оно или нет?

-- определение ieee 1471 ----------------------
Ничего непонятно
--------------------------------------------------------

-- мое определение  -----------------------------
Да, вопрос об использовании UDDI относится к архитектурным.
1. Я регулярно наблюдал проблемы гетерогенных средств связанные с отсутствием UDDI.
2. Стоимость исправления растет со временем. Конечно не так, как jra-1330, но растет.
--------------------------------------------------------

Мне не нравится определение ieee 1471. Из него непонятно, что относить к архитектурным решениям.

Концепция нравится- не нравится тут не очень подходит. Сергей, не уводи дискуссии в сторону. Мы говорим о компетенциях. Определение архитектуры оставим в стороне. Зачем выдумывать то, чего нет. Все сообщество Земли не стоит твоего мнения? Пусть.

Как я понимаю, ты считаешь, что студент должен понимать последствия архитектурной ошибки, различать архитектурные ошибки и уметь их не осуществлять (предвидеть)?

Теперь про UDDI.
UDDI само по себе рассматривать крайне странно. Это стандарт и его следует использовать в определенных стандартных ситуациях. Если ты используешь компоненты вебслужб, но вероятно не использование UDDI будет ошибкой. Правда, если его к тому времени изобретут.

Итак мы ставим еще одну компетенцию: знать что такое UDDI и уметь что? описывать расположение веб-служб? каков контекст компетенции?

Как я понимаю, ты считаешь, что студент должен понимать последствия архитектурной ошибки, различать архитектурные ошибки и уметь их не осуществлять (предвидеть)?

Предлагаю добавить еще:
* уметь классифицировать
* знать типовые ошибки разных классов систем

Итак мы ставим еще одну компетенцию: знать что такое UDDI и уметь что? описывать расположение веб-служб? каков контекст компетенции?

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

Кроме знания архитектурных ошибок есть, видимо, и другие компетенции.
* Стоит знать нотации, для описания архитектуры.

Кроме знания архитектурных ошибок есть, видимо, и другие компетенции.
* Стоит знать нотации, для описания архитектуры.

Принимается, но это знание или компетенция? Может уметь строить архитектурные вью в таких-то нотациях? Каких, на твой взгляд?