Вы новичок в архитектуре решений? Узнайте, как составить предложение для вашего следующего решения, которое понравится всем.
Быть архитектором решений — трудная, но полезная работа.
Это весело, потому что вы можете заниматься творчеством весь день, но это может быть утомительно, когда дело доходит до сбора всех ресурсов, необходимых для того, чтобы поделиться своими идеями с вашей командой.
Откуда вы знаете, что включать? С кем вам нужно поговорить?
Как мы уже знаем, быть архитектором решений — это так же много общаться с людьми, как и заниматься техническими вопросами. Это означает, что вам необходимо задействовать достаточно ресурсов для создания общего понимания с разработчиками, которые будут создавать ваше решение, и владельцами продукта, которые будут за него нести ответственность.
Сегодня мы поговорим об элементах вдохновляющего предложения по архитектуре, которое создаст общее понимание и вселит в вас доверие, чтобы ваши заинтересованные стороны были уверены в вашем решении.
1. Диаграммы, много диаграмм
Лучший инструмент, который есть у архитектора решений, — это диаграмма. Они иллюстрируют сложные понятия, абстрагируя их от кругов, овалов и стрелок. Схему может посмотреть каждый.
При правильном написании как технические, так и нетехнические люди могут уловить идею, которую вы пытаетесь донести, просто взглянув на нее. Создавая диаграммы, вы открываете двери для понимания всем заинтересованным сторонам.
Картинка лучше тысячи слов. Но когда вы говорите о концептуальном дизайне системы, они стоят около 100 000.
Существует несколько типов архитектурных диаграмм, которые вы можете использовать при построении предложения. На самом деле, я бы рекомендовал использовать несколько. Вы можете использовать различные типы диаграмм, чтобы показать различные уровни точности вашего решения.
Начните с высокоуровневых диаграмм бизнес-процессов, а затем углубитесь в детали с помощью более технических диаграмм.
ПРИМЕЧАНИЕ. При внесении предложения о серьезном изменении архитектуры не требуется подробностей реализации. Ваш уровень детализации может ограничиваться схемой сервисов (например, какие сервисы AWS подключаются друг к другу как часть решения).
2. Признайте итерации
Программное обеспечение должно быть итеративным. Мой подход к программному обеспечению состоит из трех этапов: Делай, делай правильно, делай лучше.
Идеального программного решения не существует. Признание этого с самого начала важно для установления вашего доверия. С самого начала вы должны предлагать, что нужно сделать, чтобы сделать это. Какой минимум потребуется для решения бизнес-процесса?
Разбейте разрозненные работы на модель зрелости для вашего проекта. Например, недавно я внес предложение о реструктуризации механизма авторизации во всем наборе наших облачных продуктов. Частью нового решения является создание внутренних API и регистрация различных продуктов для получения ключей API для них.
Чтобы избежать «позолоты», я построил приведенную выше модель зрелости, чтобы показать, что я знаю, что то, с чего я предлагаю начать, не является долгосрочной целью.
Решение о том, как итерировать решение, является бизнес-решением.
Когда дело доходит до выбора, что делать, это решение бизнеса, а не архитектора решений. Таким образом, предоставление путей, по которым может пойти бизнес, облегчает принятие вашего предложения.
3. Работайте в обратном направлении через предварительные условия
Почти в каждом крупном проекте будет какая-то предварительная работа. Фактически, вы часто будете видеть свои предварительные условия с предварительными условиями. Как архитектор решений, вы должны конкретно рассмотреть каждую из них.
Делая предложение, начните с конечной цели. Как выглядит окончательное решение?
После того, как вы достигнете консенсуса по готовому продукту, начните обсуждать шаги, которые необходимо предпринять для его достижения. Затем расскажите о шагах, которые нужно предпринять, чтобы перейти к этим шагам и так далее.
Причина, по которой мы начинаем с конца и работаем в обратном направлении, заключается в том, чтобы достичь скорейшего согласия и сохранить фокус. Выполните свою основную задачу, а затем начните подробно обсуждать предварительные условия.
Если вы начнете с предпосылок нижнего уровня, ваша аудитория может не иметь контекста, необходимого для того, чтобы следить за ходом ваших мыслей. Вы также можете увлечься разговором на ранней стадии, и у вас может не хватить времени, прежде чем вы расскажете об основном решении.
4. Укажите проблемы с вашим решением
Всем хотелось бы верить, что вы разработали безупречную систему, в которой никогда не будет проблем. Но как архитекторы решений мы знаем, что, к сожалению, это не так.
Важно указать на возможные недостатки в вашем предложении, чтобы заинтересованные стороны знали о риске. Вы также можете получить идеи от своей команды о том, как лучше решить проблему.
Возможные проблемы с вашим решением могут включать:
- Узкие места в масштабе
- Проблемы с прослеживаемостью через систему
- Повышение квалификации команды разработчиков
- Сложность улучшений при изменении шаблонов доступа
Это не полный список проблем, но он должен дать вам представление о том, на что нужно обратить внимание при обсуждении вашего решения.
Не бойтесь риска. Никто не любит сюрпризов.
Если вы не уверены в какой-то конкретной детали реализации, обязательно сообщите об этом. Если ваше техническое решение требует навыков, которых нет у вашей команды, упомяните, что перед разработкой необходимо пройти обучение.
Если вы с самого начала упомянете о риске, ваша аудитория будет уверена в мысли, которая легла в основу вашего решения. Старайтесь изо всех сил иметь рекомендуемые решения проблем, которые вы поднимаете, вместо того, чтобы оставлять их открытыми. Открытая проблема заставит вашу аудиторию поверить, что ваше решение неполно.
5. Получите поддержку отрасли
Всегда полезно поделиться своими идеями с кем-то еще. Я добился большого успеха, спрашивая людей за пределами моей организации, как они работают. Если вам нужны свежие мнения о том, что делают другие компании, отправляйтесь в Интернет.
Если вы проектируете систему в облаке, поговорите с представителем вашего поставщика облачных услуг. В каждом проекте, который я делаю, первыми людьми, с которыми я запускаю свое предложение, является AWS. Архитекторы решений в AWS знают все о масштабах, болевых точках и недостатках сервисов, используемых в моих планах.
Они помогают выявить потенциальные узкие места и предлагают более производительные и более дешевые альтернативы.
Если вы не знакомы с новой концепцией, спросите сообщество. В Твиттере есть прекрасное техническое сообщество, полное профессионалов, искренне желающих помочь. Задайте вопрос вслух или конкретному человеку, и вы почти всегда получите самые разные ответы.
Преимущество выхода за пределы вашей организации заключается в дальнейшем повышении вашего доверия. Работая над комментариями типа «когда я разговаривал с компанией XYZ, как они это делают, они сказали X» к своей презентации, вы делитесь работой, которую вложили в свой план. Вы продолжаете укреплять веру в то, что проделали тщательную работу по поиску наилучшего возможного решения.
Баланс между внутренним и внешним подходами даст вам четкое понимание того, как решить проблему как стандартным для отрасли способом, так и способом, который не слишком чужд вашим товарищам по команде.
6. Включите модель данных
Скорее всего, на встрече с вашим предложением будут присутствовать разные люди, от разработчиков до владельцев продукта. Простой способ заставить их концептуализировать потоки данных — представить модель данных.
Создание модели данных важно по ряду причин:
- Это показывает цель вашего решения
- Это помогает людям визуализировать, как выглядит ваше решение, зная, какие поля вы собираетесь захватить.
- Для приложений NoSQL он демонстрирует, как вы удовлетворяете шаблоны доступа.
- Это побуждает к разговору о том, как данные должны собираться и передаваться.
Владельцы продукта оценят модель данных, потому что они могут видеть, какие поля вы планируете записывать. Они могут выявить варианты использования или потенциальные шаблоны доступа, которые вы могли пропустить.
Модель данных обеспечивает детализацию вашего предложения на самом низком уровне. Это ваш лучший шанс получить полное общее представление о вашем решении.
Заключение
Цель предложения — создать общее понимание деталей крупного архитектурного проекта. Формирование общего понимания поможет повысить уверенность заинтересованных сторон и разработчиков в том, что ваше решение — правильный путь.
Рисование диаграмм и создание моделей данных помогают добиться общего понимания всей вашей аудиторией. Они поймут ваши цели и укажут на все, что вы могли упустить.
Указание на проблемы и узнавание мнений со стороны помогают повысить надежность. Вы хотите, чтобы люди поверили, что вы потратили время на то, чтобы полностью обработать решение и определить как можно больше проблем, которые могут возникнуть.
Вооружившись этой информацией, вы сможете принять свои предложения и поднять их на новый уровень.
Удачи и счастливого кодирования!
