Создание отдела архитектуры

Ответ 1

Вот несколько вопросов, о которых следует подумать:

• Каков точный мандат для команды архитектуры?
• Что представляет собой команда архитектуры? Рамки, рекомендации, помощь в реализации... Или они просто Архитектура Астронавты?
• Это только для приложений, идущих вперед, или это будет backport?
• Кто будет отвечать за бэкпорт? (И мы подразумеваем бюджет здесь...)
• Будут ли ресурсы выделены для тестирования backports?
• Есть ли у команды архитектуры настоящая мускулатура, или менеджмент будет сброситься, когда первая группа соберутся около 4 месяцев, которые потребуются для реализации изменений...
• Как вы справитесь с трением между отдельными проектными группами и командой архивирования (и будут ли трения?). Оппортунисты воспримут это как прекрасную возможность жокей за позицию...
• Имейте в виду, что это будет прежде всего политическая игра...

Друг, у вас впереди трудная дорога...

Шаг first должен быть предельно ясным в отношении того, что должна достичь команда архитектуры.
Почему вы ставите команду на место?
Вы пытаетесь объединить все приложения, разработать общую структуру, что?
Каков мандат и видение этой команды?

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

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

Ответ 2

Архитектура трудно понять.

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

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

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

Я думаю, что на другие вопросы, которые вы задаете о сфере/обязанностях/переходе, все отвечают "это зависит". Это зависит от компании, людей, денег и расписания.

Ответ 3

Интересный вопрос.

Во-первых, у вас должно быть четкое представление о том, какую проблему решает эта команда "архитектура". Если вы не можете четко определить "миссию" команды, она потерпит неудачу и сделает это с большими большими взрывами.:)

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

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

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

Я бы не привел новую группу извне. Это создало бы нежелательную динамику Us vs. Them, которая никогда не бывает хорошей. Посторонние также не имели бы представления о том, как должны работать вещи, или почему вещи не работают так, как логика подразумевает, что они должны.:)

Ответ 4

"Архитектура" в этом контексте сама по себе ничего не значит. Это означает "эксперты по трансграничным темам".

Всякий раз, когда у вас есть команда "Архитектура", у вас будет трансверсальная команда, которая будет предоставлять услуги для многих проектов.

Как указано в предыдущих ответах, вам нужно знать, какие темы должен иметь такой "Отдел архитектуры".

Теперь, вот пример организации групп архитектуры на основе нескольких тем:

• Команда
• Бизнес и функциональная архитектура: записывает множество спецификаций, связанных с бизнесом, и проверяет соответствие между существующим приложением и функциональным рабочим процессом, чтобы завершить согласованную картографию приложения. Команда
• Application Architecture: предоставляет картографию, а также определяет, как функциональные спецификации, определенные командой Business and Functional Architecture, будут организованы в приложения.
  Например, вам нужен функциональный модуль для "портфельного процесса", но команда Application Architecture может решить разбить это на "пусковую установку", "диспетчер", графический интерфейс и т.д.
• Команды технической архитектуры, всегда состоящие из:
  • Команда "Архитектура выполнения" для всех не-бизнес-чисто технических тем (протоколирование, KPI, фреймворки,...)
  • Команда разработчиков архитектуры (оценка и поддержка инструмента, технологическое исследование, управление репозиториями для контроля версий и конфигурации)
  • OA (операционная архитектура) для создания "исполняемого" среды (то есть, зная правильные процессы, правильные серверы и правильные сети для развертывания вашей системы либо для омологации, либо для производства).

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

И тебе хорошо идти.

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

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

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

Большая доработка должна включать три основных этапа:

• 1/диалог с устаревшим
• 2/завершение устаревшего
• 3/заменить устаревшее

Значение любого компонента в действительности развивается три раза!;)

Удачи и спокойной ночи.

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

Вам нужно работать через бизнес-сценарии A) и B)

A) Что делать, если вы не настроили его, т.е. ничего не делаете:
Оценки переделки на текущие расходы на техническое обслуживание

B) Затем вы настроили:
Нарушение до ближайших результатов, из-за утечки ресурсов.
В краткосрочной перспективе можно отказаться от нескольких продуктов с несколькими рисками. Стоимость предполагаемой дополнительной рабочей силы.
Кто будет отмечать, если товары будут ослаблены в результате (производительность или воспринимаемая негибкость)

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

Если вы это оправдаете, вот два маршрута, которые я видел:
1. Выберите ведущий продукт для управления архитектурой и добавления ресурсов для этого проекта.
Затем будьте готовы добавить больше ресурсов и быть терпеливыми, иначе продукт свинца будет страдать.
Вы рискуете делением на этот маршрут, он работал, когда основной продукт составлял 40% дохода.
2. Запустите небольшую команду, основанную на наиболее перспективных дискуссиях, которые происходят внутри страны, постепенно вставляйте новую архитектуру в каждый продукт.
Плетуйте, чтобы эти команды работали над работой продуктов.

Какой-то вопрос для вас посмотреть:
1. Как скоро вам нужно достичь конвергенции архитектуры, чтобы получить выгоду для бизнеса.
2. Кто из членов команды уже говорит о конвергенции архитектуры, и спрашивают/предлагают ее важность, вам нужен этот вопрос для "обратной записи" для 80% ваших сотрудников.

Что не делать
* Нанимайте экспертов извне (если только вы не находитесь в настоящем беспорядке)
  * Откажитесь от нескольких месяцев, это долгий срок.
  * Измените все проекты сразу.
  * Начните, пока у вас не будет ядра из трех, что может сделать это.
  * Позвольте отделу архитектуры стать больше, чем нужно.   * Пусть это будет воспринято, отдел архитектуры решит проблемы с командами продуктов
  * Пусть любой продукт выглядит "ожидающим новой архитектуры"
  * Позвольте отделу архитектуры "определить все" или иметь ползучесть области   * Извлеките все продукты в архитектуру, некоторые могут не соответствовать (например, не разработаны в одной стране)

Что делать:
* Вооружено хорошим оправданием от   первый вопрос получить высшее руководство   покупать и спрашивать продукт   команды сообщают о прогрессе
  * Сделайте шаг за шагом изменения в выравнивании продукта с архитектурой   карта
  * Работа по выравниванию наиболее перспективных или малорисковых товарных линий   первый
  * Установите показатели, чтобы продемонстрировать добавление значения (см.   обоснование из набора   вопросы)
  * Сделайте дорожную карту для всех продуктов, чтобы получить конвергенцию или нет.
  * Подумайте, что обеспечивает основная архитектура и кто ее поддерживает.   артефакты
  * Разрешить командам продуктов вносить вклад в ядро ​​с точки зрения   специфика, код и обслуживание   основного ядра   * Настройте учебник о том, как использовать работу команды архитектуры для   новые стартеры и существующие команды

Ответ 8

Только архитектура может превратить людей в космонавтов/зомби. Поэтому им обязательно нужно кодировать, даже если это базовое прототипирование. Фактически успех их прототипов должен быть определенным фактором обзора.

Они должны выставлять ежемесячные презентации/частые блоги, отслеживающие их работу, чтобы другие в организации могли учиться.

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

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

Они несут ответственность за то, чтобы выполнить по крайней мере 3-4 обзора кода критических модулей и разработать правила стиля кода.

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

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

У них должна быть возможность отказаться от архитектуры и вернуться к обычной работе, если они чувствуют, что это не связано со штрафами.

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

Они должны обладать высокотехническим персоналом в качестве своего менеджера.

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

По крайней мере, одна реальная цель (например, объединить все общности между проектами в одну библиотеку) каждые 1 год

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

Ответ 9

Рассмотрите возможность чтения/покупки этой статьи из ACM: Архитектор программного обеспечения. Там есть несколько ссылок, и автор необычайно ясен в такой рассеянной теме. Он не будет отвечать на ваши вопросы напрямую, но в статье будет сосредоточена ваша стратегия.

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