Иван, приятно тебя читать :)
Я не помню, чтобы на моем опыте архитектор руководил изменениями процессов, кроме как в случае совмещения функций главного менеджеров (зверь ака "Генеральный конструктор"). Обычно садится группа людей и обсуждает, как и что и по каким причинам лучше делать.
Ты описал какого-то убер-специалиста, обычно такие уже идут выше, в СТО или ему подобное.

Это зона ответственности примерно любого EA и некоторых Solutions архов

По смыслу я польностью согласен, но вы чрезмерно завысили требования к "арху-гениусу":)

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

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

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

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

@emacsway cкорее не завысил, а раскрыл в лимите. Ну, это что-то вроде "Идите в Десант"! И показывается как это круто.
Но это тоже деду надо, так как показывает вектор роста и потенциал.

Видимо в реалии это все обстоит внутри этих границ. И видимо реалии обусловлены реалиями - конкретным окружением, конкретным применением и конкретным текущим опытом Роли (выполняющей функцию).

Я бы добавил несколько стейтментов. Арх способен работать в условиях неопределенности (скорее всего через фиксацию системы координат) и способен принимать решения в условиях минимальных данных.

#работа #сдельная #вакансия #удалённо #job #remote #parttime

Господа, здравствуйте. Пост не то чтобы про вакансию, но про работу.

Если вы занимаетесь архитектурой решений, именно проектированием и используете в своей работе такие вещи как, например, protege, owl, kb, инженерия знаний, онтология и тд - все не буду перечислять, так как контекст понятен. Это системы основанные на знаниях. Это не совсем ML, но иногда он тут есть.

Прошу откликнуться @momentics для продолжения.знакомства. Уверен, вам будет интересно.

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

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

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

Очень хорошо, что Neal Ford и Gregor Hohpe включили некоторые управленческие аспекты в свои книги по архитектуре. Я считаю это спасительной соломинкой для перегруженного мозга современного архитектора, которому непросто изыскать время на это.

Вопрос совершенствования имеет иную плоскость. Повторюсь, вы доводите ситуацию до абсурда.

ЖЦ существует даже если один программист выпускает свой pet-проект. Как же он это делает ничего не зная о ЖЦ?

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

Надеюсь, аллегория понятна.

Убиваться перфекционизмом так же плохо, как ничего не делать вообще. ИМХО.

https://t.me/itarchitect коллеги, а пойдемте вот сюда. Там как раз чат для обсуждений, а здесь все-таки для работы + коротких обсуждений, с ней связанных.

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

Вопрос в том, что подход ЖЦ позволяет более гранулярно взглянуть на суть ядра эпохи потребления, где ЖЦ тоже должен планироваться.

В качестве примера приведу элемент ЖЦ, например, срок эксплуатации. Где можно заложить пластика такой толщины, что ровно через 3 года изделие умрет. Конечно, это позволит экономить, например.

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

Кстати, о "психологической защите". Вот тут доходчивей, чем в Википедии.

> ЖЦ существует даже если один программист начинает выпускает свой pet-проект.

Очень интересный пример для демонстрации процессных проблем масштабирования команд, по всей вероятности, говорящий о масштабах вашего опыта. Matthew Skelton нервно покуривает в сторонке. В таком случае, соглашусь, даже single-team Scrum guide будет перфекционизмом.

> Как же он это делает ничего не зная о ЖЦ?

Ну все, все... Я уже все понял. Вопрос исчерпан 🙌. Управление циклом разработки вы уже продемонстрировали на примере pet-проекта с командой из одного человека.

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

Опять холивары....
Только в соседнем чате.
@momentics , аккуратнее, а то банить будут.
Тишина в чате, не хорошо, кончено...
Но и гиперактивность — зло

Пожалуйста ко мне не обращайтесь никогда. Вроде бы это уже сказал. Занимайтесь своими делами.

Оу.. оу.. :))  Вы не находите, что ваши аргументы вышли на тонкий край личных оскорблений?

И конечно, Вы не просто ответили. А явно нуждались в прилюдном ответе. Т.к. было задето Ваше чистолюбие;)

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

Сорри за оффтоп, а можно посмотреть блог пост с рекомендованной литературой?

#вакансия #офис #Москва #АрхитекторИБ #fulltime
 
Вакансия: Архитектор ИБ
Локация #Москва
З/п: 150– 300k p.
Компания: Код Подбора
Контакты:  @dashikin88
 
Обязанности:
• Функциональная декомпозиция информационных систем
• Разработка требований к микросервисным архитектурам, контейнерным архитектурам
• Участие в процессе согласования проектных документов
• Технический анализ на этапах разработки/доработки/внедрения/эксплуатации средств обеспечения ИБ.
• Проведение анализа защищенности корпоративных ресурсов. Сканирование локальной сети и веб-приложений на наличие уязвимостей
• Автотесты (комплайнс тесты Chef InSpec)
• Написание скриптов для автоматизации своей деятельности, написание скриптов для встраивания СЗИ в конвейеры CI/CD
• Проектирование средств защиты компьютерных сетей и информационных систем Банка
• Разработка и совершенствование механизмов защиты ресурсов Банка
• Внедрение средств защиты клиентов и денежных средств Банка
• Стандартизация настроек ПО и оборудования в части ИБ
Требования:
• Понимание гибких методологий (итеративная разработка, работа в Jira)
• Понимание архитектурный стиль взаимодействия компонентов распределённого приложения (REST API)
• Понимание сетевой модели OSI
• Понимание принципов организации SSL соединений, VPN
• Знание основ построения локальных сетей, межсетевого экранирования и инспекции трафика
• Опыт проектирования сетевой инфраструктуры
• Знание Windows и Linux на уровне администратора
• Знание платформ контейнерной оркестрации Kubernetes (k8s), OpenShift,  и средств обеспечения их безопасности (Aqua, Prisma, Twistlock, SysDig, Falco), понимание жизненного цикла контейнеров, специфичных уязвимостей
• Разработка скриптов при помощи современных инструментов разработки (хотя бы один современный язык программирования, например Python, Golang), системы контроля версий (Git, GitLab)
• Знание средств автоматического тестирования (фреймворки специфичные для вашего языка)
• Знание средств автоматического анализа уязвимостей в SAST/DAST/IAST, особенностей их интеграции в конвейер CI/CD
• Знание систем документирования взаимодействия микросервисов (например, на базе OpenAPI, Swagger)
• Знание системы мониторинга (Prometeus)
• Знание системы обнаружения сервисов (service discovery) (etcd, Consul)
• Знание системы управления секретами (Vault, Conjur)
• Знание системы логирования (ELK, Graylog2)
• Знание SQL (PostgreSQL)
• Знание NoSQL (MongoDB)
• Знание  какого либо брокера сообщений (Kafka, RabbitMQ, ActiveMQ)
• Знание  какого либо Хранилища key-value (Memcached, Redis)
• Знание  какого либо Реверс-прокси (Nginx, Envoy, Apache, HAProxy)
• Знание  какого либо Веб-сервера (Nginx, Apache)
• Знание  какого либо cистемы управления конфигурациями (Ansible, Puppet, Chef, Salt)
• Серверов приложений (Tomcat, WildFly)
• Готовность работы с документами (Бизнес требования, Технические задания, Схемы и тп)
 
Подробнее пишите: @dashikin88
#АрхитекторИБ #Работа
 

#вакансия Компания Gost group - крупнейший интегратор и разработчик госзаказов ищет технического архитектора.
Требования к специалисту:
Опыт работы в ИТ в роли системного архитектора или аналитика (системного и бизнес) с практическим опытом разработки детальных требований и вывода в промышленную эксплуатацию проектов от 3 лет.
Опыт промышленной разработки c использованием стека Java, Python, Angular/React от 2 лет.
Опыт в проектировании, работе, оптимизации с реляционными (PostgreSQL, Oracle) и NoSQL (Elastic, Mongo, Redis) базами данных.
Формат работы: Гибрид
Зарплатная вилка: 250-400

Так опыт аналитика или опыт разработки?
Локация - дефолт сити?
... Так вам сложно найти кого-то будет

Локация - дефолт сити? Да, они в районе Красносельской находились раньше

"разработки детальных требований"