Pull to refresh
120
-3
Роман @rpiontik

Archi Product Owner

Send message

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

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

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

Главная причина подхода в том, что он встраивается в DevOps как активный элемент. Т.е. может исполняться и приносить результат.

Например, арх спроектировал АС и предал в производство. Разработчик получил доступ к ее описанию в среде разработки. Декомпозировал описание на модули. Написал код и разметил его на АС как объект архитектурного учета. Передал DevOps для развертывания. Тот, в своей среде разработки, обогатил арх описание метаданными развертывания.

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

Слабо представляю, как это можно сделать в draw.io или PlantUML.

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

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

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

Поживем, увидим.

Чтобы что-то скопировать, нужно понимать как это работает. А оно на русском... шах и мат.

Если серьезно, плз, перечитайте мой первый пост в треде. Будет что переводить - переведу.

К сожалению, структурайзер обладает всеми выше описанными проблемами.

В планах поддержка различных языков. В том числе Structurizer, Mermaid и т.д. Что касается C4 то она также поддерживается в DocHub. Но эта нотация имеет ряд недостатков. Я оних рассказывал в прошлой статье - https://habr.com/ru/post/593009/

Я все же сфокусируюсь на Российском рынке. Кто-то же должен это сделать.

Если есть возможность, пожалуйста, пришлите трейс в личку и версию IDE.

На сколько мне известно - нет. Мне кажется, что искал я хорошо. Есть автогенераторы кода. Есть EAM системы для крупных компаний. Инструментов управления архитектурой приземленного в команды (тем более с подходом "архитектура как код") я не встречал.

Не говорю, что их нет. С удовольствием бы сам о них узнал.

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

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

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

Кажется, что сейчас опрос не несет ценности.

1. Опрос проводится сегодня. Т.е. тогда, когда аудитория Хабра УЖЕ изменилась. Все, что получит команда Хабра - констатацию факта, который он и так знал.
2. Не ясна цель опроса. Кажется, что Хабр что-то хочет изменить... но что именно? Мало пользователей? Много (сложно управлять) и хотим сфокусироваться? Хотим вывести площадку на новый уровень?

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

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

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

По меньшей мере необоснованы.

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

Тогда сколько будет стоит такой компонент? И как можно будет его выпустить на гражданских линях, которые настроены на миллионы и миллиарды штук?

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

Можно прфу, скажем о производстве в США для военной промышленности?

Спорить тут не с чем. Вполне вероятно, что в ваших словах есть существенна доля истины.

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

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

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

Смотрите, сколько у вас суждений:
1. быстро создавать - откуда данные? Насколько быстро? А так нужно было? Кому?
2. качественную аппаратуру - откуда данные? Насколько качественную? Какой % брака в сравнении с текущим выпуском? Какой срок службы? и т.д.
3. в общем-то заслуга именно того периода - откуда данные? И т.п.

И вот на базе этих суждений, вы делаете вывод...

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

Уверен, что вопрос был риторическим.

Вопросы в целом, хороши. Они объединяют людей. А вот ответы, в целом, плохи. Потому, что они разобщают людей по их мнениям. (с)

Не задавай вопрос, ответ на который не хочешь услышать (с)

Я ничего не рашал. Так в статье написано.

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

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

Во всяком случае, я почти уверен, что сравнивать с гражданским выпуском аппаратуры цены и сроки на комплектуху не стоит.

А то, что у нас одно время гнали комплектуху в военку с алиэкспресса за три недели... у меня скорее к этому вопрос.

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

Последнее, что подозрительно - документация. Конечно очень странно, что ее нет в нужно объеме и качестве. Но, может быть для этого есть причины? Ну например, мелкосерийность может подразумевать проектность выпуска. А это, в свою очередь, уникальность характеристик под заказчика и уникальность документации для этого заказчика.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity