Size: a a a

Архитектура ИТ-решений

2020 April 05

I

Irina in Архитектура ИТ-решений
Fagor
только опыт, и здравый смысл, в первый раз накосячите - главное на подчинённых больше работ не вешайте и в кранч не вводите отдел разработки ( а то за г будут вас считать), потом научитесь. И кстати некоторым подчинённым бывает видней верное направление. После первого косяка, умейте признать ошибку и свалить в другую контору или свапнуть решение (принять на себя удар того что 10 в 6 баков будем свапать еще раз). Хорошая мина при плохой игре погятна всем, не важно как вы пытаетесь. просто начальству выгодно или плевать. А подчинённые и отдел разработки вас за г* будут считать.
Сейчас скажу, как наш Главный говорит - у нас нет права на ошибку )) Ошибка проектирования - очень дорогой становится, если доходит до разработки, не говоря уже о внедрении. И у меня сейчас предметный интерес прожить весь путь вместе со своим проектированием.
источник

d

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

П

ПашМиш in Архитектура ИТ-решений
Irina
Сейчас скажу, как наш Главный говорит - у нас нет права на ошибку )) Ошибка проектирования - очень дорогой становится, если доходит до разработки, не говоря уже о внедрении. И у меня сейчас предметный интерес прожить весь путь вместе со своим проектированием.
Я где-то читал про компанию, которая при найме больше ценила PMов, которыеимели в портфеле не только успешные, но и провальные пректы. За одного битого...
источник

П

ПашМиш in Архитектура ИТ-решений
Возможно с арихитекторами так же)
источник

F

Fagor in Архитектура ИТ-решений
Irina
Сейчас скажу, как наш Главный говорит - у нас нет права на ошибку )) Ошибка проектирования - очень дорогой становится, если доходит до разработки, не говоря уже о внедрении. И у меня сейчас предметный интерес прожить весь путь вместе со своим проектированием.
Права может и нет, а ошибки будут, серьезных ошибок не допустит тот кто выстрадал их на других местах, или на этом месте давно и хорошо лавирует между-между, если вы недавно в принципе в сфере, в конторе, не знаете ит ландшавт с чем работать предстоит именно тут, вплоть до конечных исполнителей и пользователей, их мелких целей, а так же вообще логики финансирования проекта, Без ошибок не обойтись.
источник

I

Irina in Архитектура ИТ-решений
Maxim Smirnov
В BABOK Guide номер 3 прослеживается мысль, что SA - это частный случай BA. Аналитики разные бывают, кто-то в бизнес-процессах разбирается, кто-то в business intelligence, а кто-то в ИТ. Этакий Business System Analyst
где-то на просторах FB спорили из кого должен вырасти системный архитектор - из BA или разраба. В какой-то момент решили, что если бы не было SA (на прошлой работе так и было), то проектированием архитектуры решения занимались бы бизнес-системный аналитик и разраб (на прошлой работе так и было). Потому что аналитик понимает контекст и потребность, разраб знает как реализовать потребность. Я в основном бизнес-системный аналитик с небольшим опытом разработки (БД) и системного администрирования и сейчас, участвуя в проектировании решения, сейчас  понимаю, что очень не хватает хорошего бэкграунда разработки.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
ПашМиш
Возможно с арихитекторами так же)
А не понятно, что такое "провальная" архитектура.
источник

П

ПашМиш in Архитектура ИТ-решений
Irina
Сейчас скажу, как наш Главный говорит - у нас нет права на ошибку )) Ошибка проектирования - очень дорогой становится, если доходит до разработки, не говоря уже о внедрении. И у меня сейчас предметный интерес прожить весь путь вместе со своим проектированием.
Фредерик Брукс в своей книге "Мифический человеко-месяц" прямо говорит "планируйте выбросить первую версию - вам все равно придется это сделать" https://econ.wikireading.ru/78632.

Стив Макконнелл в совей книге "Совершенный код" называет проетирование ПО "грязной проблемой", понимая под этим, что "проблему нужно «решить» один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения" https://medium.com/@a8h333/%D0%B3%D1%80%D1%8F%D0%B7%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-d5264a9893a8.

Мартин Фаулер опубликовал статью "Сперва монолит": https://martinfowler.com/bliki/MonolithFirst.html .

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

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, архитектура - это не артефакт, а процесс.
источник

П

ПашМиш in Архитектура ИТ-решений
Вот да)
источник

I

Irina in Архитектура ИТ-решений
ПашМиш
Фредерик Брукс в своей книге "Мифический человеко-месяц" прямо говорит "планируйте выбросить первую версию - вам все равно придется это сделать" https://econ.wikireading.ru/78632.

Стив Макконнелл в совей книге "Совершенный код" называет проетирование ПО "грязной проблемой", понимая под этим, что "проблему нужно «решить» один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения" https://medium.com/@a8h333/%D0%B3%D1%80%D1%8F%D0%B7%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-d5264a9893a8.

Мартин Фаулер опубликовал статью "Сперва монолит": https://martinfowler.com/bliki/MonolithFirst.html .

По какой-то причине общепризнанные гуру полвека стелят соломку на случай, что с первого раза построить правильную архитектуру не получится. Возможно и вам стоит быть к этому готовой.
Я немного шутила про Главного. Конечно, я понимаю, что ошибка - это возможность увидеть еще одно, возможно верное решение. За  ссылки и выдержки спасибо )
источник
2020 April 06

DM

Denis Migulin in Архитектура ИТ-решений
ПашМиш
Фредерик Брукс в своей книге "Мифический человеко-месяц" прямо говорит "планируйте выбросить первую версию - вам все равно придется это сделать" https://econ.wikireading.ru/78632.

Стив Макконнелл в совей книге "Совершенный код" называет проетирование ПО "грязной проблемой", понимая под этим, что "проблему нужно «решить» один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения" https://medium.com/@a8h333/%D0%B3%D1%80%D1%8F%D0%B7%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B-d5264a9893a8.

Мартин Фаулер опубликовал статью "Сперва монолит": https://martinfowler.com/bliki/MonolithFirst.html .

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

П

ПашМиш in Архитектура ИТ-решений
Это как?
источник

f

folex in Архитектура ИТ-решений
День добрый! Чтобы описать RPC для системы из нескольких узлов лучше Modelio или Papyrus?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А не Swagger?
Т.е. что значит "описать"?
источник

f

folex in Архитектура ИТ-решений
Нарисовать, чтобы был артефакт, который можно предметно обсуждать с коллегами
источник

f

folex in Архитектура ИТ-решений
Важно показать состояние полей в RPC, какое поле как меняется при форварде запроса, что к чему относится, какое состояние приходится хранить узлам
источник

f

folex in Архитектура ИТ-решений
И конечно же, как узлы между собой связаны (логически)
источник

f

folex in Архитектура ИТ-решений
Хотя видимо всё же lucidcharts. Думал десктопное что-то попробовать, но papyrus не запустился (привет, eclipse), а в modelio какой-то мрак :)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Тогда это похоже на sequence diagram с комментариями. Это draw.io
источник