Каждый клиент имеет важное значение
Одним из ключевых принципов проектирования платформы является оптимизация для клиентов. Думайте о разработчиках в качестве основного клиента и сосредоточьтесь на своих потребностях в первую очередь при выборе путей разработки, которые вы хотите проложить. Разработчики все используют различные средства для выполнения работы. На первом шаге начните с малого и оцените, можно ли улучшить существующие экраны и поверхности перед реализацией новой внутренней платформы разработчика.
Предоставление разработчикам возможностей с помощью внутренней платформы, ориентированной на клиента
Думать о разработчиках в качестве основного клиента для внутренней платформы разработчиков важно для его успеха. Мы будем ссылаться на этих клиентов как разработчиков, однако они могут быть любым участником того, что модель топологий команд называется группами, выровненными по потоку, включая роли, такие как специалисты по машинному обучению или специалисты по обработке и анализу данных.
Успешная практика проектирования платформы позволяет разработчикам и операторам. Разработчики и операторы имеют автономию принимать решения, которые обеспечивают бизнес-ценность, сохраняя соблюдение установленных стандартов, управления и правил безопасности. Критически важные заинтересованные лица, позволяя командам и экспертам в конкретных подсистемах (операции, безопасность, соответствие и архитектура) работать с командой, создавая эту внутреннюю платформу, чтобы совместно использовать свои знания и рекомендации в шаблонах и системных возможностях. Перемещение этих знаний в систему одновременно снижает когнитивную нагрузку для разработчиков, улучшает безопасность, соответствие и качество, а также улучшает масштабирование этих других ролей для решения действительно уникальных проблем. Однако это опыт разработчика, который гарантирует, что ваша платформа возвращает наибольшее преимущество для всех участников.
Это означает, что после клиентского подхода к планированию и приоритету ваших усилий по проектированию платформы.
Определение оптимальных путей разработки для оптимизации рекомендаций
Хотя у вашей организации могут быть различные пути разработки к рабочей среде сегодня, ранним шагом в разработке платформы является понимание того, какие пути вы хотите использовать разработчикам. Этот вызов важен, так как он позволяет сосредоточить вашу энергию на прокладке эффективного пути через них, который по-прежнему соответствует требованиям разработки, операций и управления.
Эти проложенные пути представляют собой определенный набор средств разработки и наблюдаемости, языков, пакетов SDK и служб, которые формируются в соответствии с тем, какие разработки, операции и другие заинтересованные лица согласны представлять свои рекомендации. Проложенные пути должны включать подходы к упрощению подключения, модерации и пропаганды внутреннего повторного использования. Вам не нужно думать об этих проложенных путях как ограничительных или принудительных, но вместо сокращения нагрузки разработчиков до точки разработчиков хотят остаться в них.
Тем не менее, трюк заключается в том, чтобы понять не только какие пути сосредоточиться на, но какие части пути необходимо проложить сначала.
Знакомство с пользователями, где они находятся
Хотя это может быть заманчиво начать с единого портала для всего в вашей внутренней платформе разработчика, это не лучший отправной пункт.
Специалисты по работе, инженеры надежности сайта (SREs) и разработчики используют различные средства для выполнения своей работы. Кодирование происходит в интегрированной среде разработки, такие как GitHub и Azure DevOps, используют интерфейсы командной строки, а совместная работа в режиме реального времени выполняется в Teams и Slack. Часто эти пользователи довольны этими экранами и опасаются еще одного пользовательского интерфейса, чтобы беспокоиться о них.
Начните с малого и оцените, можно ли улучшить существующие экраны и поверхности, создать подключаемые модули или расширения перед началом создания новых пользовательских интерфейсов. Спросите себя, будут ли люди реагировать лучше на другой новый интерфейс пользователя или улучшенную версию чего-то, что у вас сейчас? Если вы решите создать портал с нуля, фактор в идее, что вы, скорее всего, хотите поддерживать несколько интерфейсов через API. Это также разблокирует такие варианты, как использование платформ с низким кодом, поэтому вам не нужно создавать и размещать интерфейс портала с нуля.