«Расспрашивает об уже имеющихся функциях системы» — и не просто расспрашивает, а бывает, что и смотрит код, чтобы понять, какой в итоге алгоритм реализован. Часто это необходимо, когда нужно определить способ устранения ошибки или причину ошибки в самом реализованном алгоритме. Расспрашивать о функциональности тоже приходится. Особенно, если система очень большая, над ней работают несколько команд, и на старте работ нет аналитика. Он (аналитик) потом обязательно появится и займется описанием и сбором требований для новых возможностей системы. Ему тоже важно знать, что уже есть в системе, и он об этом расскажет. Это и есть плюсы командной работы.
«Описывает требования, которые должен реализовать разработчик» — это тоже важно описать. Здесь важен уровень детализации и количество команд, которые участвуют в реализации решения. Возможно, при построении архитектуры одной маленькой системы, не связанной с другими системами, сами разработчики могут и знать, что уже есть в системе. Разобраться, кому из них и что запрограммировать. Но когда в решении участвует много команд, когда есть интеграции, очень важно, чтобы хотя бы кто-то один видел решение целиком от начала и до конца. И тогда условно, команда, которая «пуговицы очень хорошо пришивает», от архитектора получит информацию, где именно пришить эти пуговицы. При этом ему не нужно объяснять, как их пришивать. Команда итак хорошо умеет делать свою работу. Команда, которая «делает петли», по задаче архитектора, сделает их именно там, где потом ровным стройным рядом можно будет застегнуть пуговицы.
Образование: «Программное обеспечение вычислительной техники и автоматизированных систем», г. Оренбург.
Реляционные и документориентированные СУБД от запросов до пакетов (Orcle/MS SQL/LotusDomino).
Программирование: от бека до фронта, интеграции. Языки: PHP, JavaScript, C#, в том числе разработка аддонов под продукты MS
Несколько лет управления ИТ-отделом, где удалось создать две команды разработки с нуля и выполнить несколько проектов. В последнее время — архитектура.
к информационной безопасности (на этапах аутентификации, авторизации);
по нагрузке и времени отклика, например, 100 запросов одновременно и время отклика 50мс;
по времени простоя и восстановления системы;
атрибуты качества. Они помогают отслеживать ошибки системы. Например, 99% процесса покупки прошло успешно, но где-то возникла ошибка и нужно понять, где именно. Отследить, на каком этапе недоработка.
по поддержке и эксплуатации, например, наблюдаемость и UI для техподдержки. Наблюдаемость — это записи о каждом действии в системе — кто, где и что изменил. Нужна для выявления багов, подозрительных активностей. UI — чтобы эти записи смотреть и анализировать.
Это основные и самые частые. Вообще про все требования можно книгу отдельную писать.
У нас роль Application/Software Architect выполняют разработчики. И, конечно, они пишут код. Статья в большей степени о Solutions/SystemsArchitect.
«Расспрашивает об уже имеющихся функциях системы» — и не просто расспрашивает, а бывает, что и смотрит код, чтобы понять, какой в итоге алгоритм реализован. Часто это необходимо, когда нужно определить способ устранения ошибки или причину ошибки в самом реализованном алгоритме. Расспрашивать о функциональности тоже приходится. Особенно, если система очень большая, над ней работают несколько команд, и на старте работ нет аналитика. Он (аналитик) потом обязательно появится и займется описанием и сбором требований для новых возможностей системы. Ему тоже важно знать, что уже есть в системе, и он об этом расскажет. Это и есть плюсы командной работы.
«Описывает требования, которые должен реализовать разработчик» — это тоже важно описать. Здесь важен уровень детализации и количество команд, которые участвуют в реализации решения. Возможно, при построении архитектуры одной маленькой системы, не связанной с другими системами, сами разработчики могут и знать, что уже есть в системе. Разобраться, кому из них и что запрограммировать. Но когда в решении участвует много команд, когда есть интеграции, очень важно, чтобы хотя бы кто-то один видел решение целиком от начала и до конца. И тогда условно, команда, которая «пуговицы очень хорошо пришивает», от архитектора получит информацию, где именно пришить эти пуговицы. При этом ему не нужно объяснять, как их пришивать. Команда итак хорошо умеет делать свою работу. Команда, которая «делает петли», по задаче архитектора, сделает их именно там, где потом ровным стройным рядом можно будет застегнуть пуговицы.
Доброго дня!
Образование: «Программное обеспечение вычислительной техники и автоматизированных систем», г. Оренбург.
Реляционные и документориентированные СУБД от запросов до пакетов (Orcle/MS SQL/LotusDomino).
Программирование: от бека до фронта, интеграции. Языки: PHP, JavaScript, C#, в том числе разработка аддонов под продукты MS
Несколько лет управления ИТ-отделом, где удалось создать две команды разработки с нуля и выполнить несколько проектов. В последнее время — архитектура.
Всегда есть следующие требования:
к информационной безопасности (на этапах аутентификации, авторизации);
по нагрузке и времени отклика, например, 100 запросов одновременно и время отклика 50мс;
по времени простоя и восстановления системы;
атрибуты качества. Они помогают отслеживать ошибки системы. Например, 99% процесса покупки прошло успешно, но где-то возникла ошибка и нужно понять, где именно. Отследить, на каком этапе недоработка.
по поддержке и эксплуатации, например, наблюдаемость и UI для техподдержки. Наблюдаемость — это записи о каждом действии в системе — кто, где и что изменил. Нужна для выявления багов, подозрительных активностей. UI — чтобы эти записи смотреть и анализировать.
Это основные и самые частые. Вообще про все требования можно книгу отдельную писать.