Как стать техническим архитектором?

Question

Я потратил более 3 лет на программирование в DotNet (C#) и теперь хочу изучить основы и дизайн.

Я решил стать хорошим архитектором в будущем. Я знаю, что для этого мне нужно много работать. Я готов сделать это.

Что я не знаю, это как начать?

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

Спасибо

Answer 1

Обновление: обе ссылки не работают, я постараюсь найти заменяющий контент, но пока что на этой странице есть список разных типов архитекторов, FWIW: http://en.wikipedia.org/wiki/Systems_architect

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Это зависит от того, что вы называете " Техническим архитектором", а также от того, куда вы хотите отправиться. Кроме того, ваш опыт (насколько вы его описали) связан с программированием / программным обеспечением, поэтому термин "Техническая архитектура" может не соответствовать вашему.

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

Мой общий совет тебе такой:

• Исследования: читайте книги, статьи, блоги и (самое главное)...
• Взаимодействие: поговорите с настоящими архитекторами о том, что они делают и как они туда попали. Конечно, вы можете задавать вопросы на таких форумах, как этот, но вы ищете глубокое и глубокое обсуждение, а не только один или два. Один из способов сделать это, чтобы...
• Присоединитесь к местному форуму архитекторов или общественной группе в вашем районе или посетите странную беседу. У больших конференций, таких как Tech Ed, будет архитектурный трек, так что следите за интересными темами.
• Ждем вас: я получил официальное название "Архитектор решений" после 8 лет в разработке программного обеспечения, что, вероятно, быстро; так что приготовьтесь к долгому, но "глубокому" путешествию.
• С точки зрения домена вы хотите остаться в программном обеспечении или перейти в инфраструктуру? Специалист по безопасности возможно? Единственный способ узнать это - испачкать руки на некоторых из них; и наличие большого количества маленьких знаний (таких как инфраструктура, безопасность, данные) хорошо увеличивает глубокий "центр тяжести" в чем-то вроде архитектуры программного обеспечения.

Вещи, чтобы рассмотреть на пути:

• Быть архитектором - это не просто придумывать технические решения для технических проблем, это также (по крайней мере, половина) о "мягких навыках"...
• Ведущие команды разработчиков / проектные группы, консультирование руководителей проектов; они будут обращаться к вам за советом.
• Устранение неоднозначности, решение противоречивых потребностей. анализ проблем бизнеса и др.
• Думать за пределами площади и задавать (переспрашивать) основные вопросы, например: Вопрос: "Какой лучший способ сделать Х?", Ваш ответ: "Почему Х в первую очередь?"

К вашему сведению, " Стремящиеся архитекторы" - моя любимая тема.
Обновление январь 2017 - наконец-то обновлена ​​неработающая ссылка (контент написан в 2010 году!) И, кроме того, добавлена ​​новая ссылка, касающаяся определения архитектурных ролей.

Answer 2

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

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

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

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

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

Answer 3

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

1. Все дело в построении системы, которую можно поддерживать с течением времени. Тестируемость и модули являются ключевыми!
2. Вы должны знать о шаблонах и понять, когда они могут помочь и почему
3. о различных технологиях, о том, как они работают, и как их склеить
4. "о настройке большой системы, чтобы ее можно было использовать в разных контекстах с минимальными усилиями
5. "об инструментах, которые могут измерить хорошую архитектуру, такую ​​как pmd, findbugs в мире Java
6. "о настройке кода, тестирования, сборки среды, которая позволяет гибкую разработку...
7. и многое, многое другое...
8. Архитектура системы - это огромная ответственность, и если сделать ее неправильно, она может все испортить

Лично я не позволил бы кому-то принимать какие-либо большие архитектурные решения без опыта менее 10 лет.

Answer 4

Я думаю, что для того, чтобы быть хорошим техническим архитектором, вы должны хорошо разбираться в шаблонах проектирования, WCF, WPF, инструментах отчетности, C#, SQL Server и т. Д.