Начало системной архитектуры. Философия и язык. Часть 1

[sllh]

Одна из трудностей документа архитектуры – частые изменения. И здесь нет однозначной методики контроля и ведения истории данных изменений

Вообще-то есть :) Смотрите SEI, у них есть даже отдельный курс про документацию.

В целом по тексту, сложилось впечатление, что автор романтизирует профессию и считает, что архитектор такой себе «вольный художник». На практике, такое возможно только в маленьких проектах. Все остальное давно формализовано, существуют подходы по вычленению наиболее важных quality attribute'ов, фреймворки для нахождения architecture trade off'ов и т.п. По факту, архитектор в современном мире — это человек, грамотно проецирующий свой багаж знаний (и умеющий его быстро пополнить, если необходимо) на конкретную проблему, при помощи разработанных подходов, а-ля best practices.

[valis]

Про SEI спасибо, но про вольного художника Вы не правы. Смотрите заголовок статьи — ключевое слово «философия». Разработка ПО всегда поиск компромиссов, и выше стандартов стоят внутренние правила и политика компании.

[sllh]

Внутренние правила и политика компании не имеют никакого отношения к стандартам. Это дополнительные ограничители (атрибуты) при поиске трейдоффов.

[lair]

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

А опыт программирования у вас есть?

места архитектора в крупной компании

Вы про какого архитектора говорите — архитектора системы (system architect), архитектора решения (solution architect) или архитектора предприятия (enterprise architect)?

[sllh]

А так же application, principal, data, тысячи их :)

[valis]

А опыт программирования у вас есть?

Практического опыта нет

Вы про какого архитектора говорите — архитектора системы (system architect), архитектора решения (solution architect) или архитектора предприятия (enterprise architect)?

У нас нет настолько специфического разделения ролей.
Подскажите, возможно я ошибаюсь, но это специфично исключительно для IT компаний.
Компания, в которой я работаю действительно крупная (по всем меркам).

[lair]

Практического опыта нет

Тогда как вы можете рассуждать об архитектуре ПО?

Подскажите, возможно я ошибаюсь, но это специфично исключительно для IT компаний.

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

[valis]

Здесь есть архитекторы, которые пришли не из программистов?

[deilux]

Я рискну объяснить, почему люди так отреагировали на эту статью.

Архитекторы действительно бывают разные, с разными зонами ответственности.

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

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

Вы, скорее всего, пишете про архитектору предприятия. Здесь действительно, на мой взгляд, необходимы навыки системного администрирования. Задачи и ответственность в принципе понятны из названия — грамотно построить IT-инфраструктуру предприятия, с оглядкой на бизнес.

Однако встречаются абзацы типа:

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

и

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

Это — ответственность архитектора ПО \ техлида. Он обязан иметь глубокие познания в разработке и архитектуре ПО, иначе банально не справится с задачами (т.к. ему необходимо принимать решения за\для программистов). Карьерный путь с простого разработчика до этой должности занимает 5+ лет.

[lair]

Системные архитекторы — насколько я понимаю, отвечают за интеграцию компонент одной системы или разных систем.

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

[deilux]

Окей, за архитектуру конкретной системы и соот-но интеграцию её модулей друг с другом :-)
Развелось их, блин! И каждым хочется поработать :-)

[lair]

В принципе, переход по цепочке application/system/solution в обе стороны происходит достаточно прозрачно и требует просто достаточной квалификации. Вот enterprise — это уже скачок уровня.

[deilux]

Но здесь, наверное, навыки разработки уже не так важны?

[lair]

Для enterprise — нет, не так важны. Но зависит от природы предприятия.

[valis]

Тем кто минисует и тролит на тему «Насколько я крут, а ты г@@но»
— Вы работаете в IT компаниях, не так ли? Не забывайте в компаниях не IT профиля тоже есть хорошие группы разработки.
— Именно в Вашей компании есть по крайней мере 4 различных роли архитекторов (не говоря уже о сотне)?
Минусуйте, я не прав.

[grossws]

Из при ведущего абзаца следует главное отличие ремесел системного архитектора и градостроителя.

Оценил шутку. <sarcasm>Бьюсь в конфуциях.</sarcasm>

Обычно об ошибках в личку, но это из ряда вон.

[valis]

Из при ведущего

сам в шоке — исправил.