lytdybr
Вчера провёл пятый день СМС24, довольно долго разбирались с предметными областями на примере архитектуры. Конечно, затрагивали немного и основную тему дня: управление изменениями и лидерство, работу с живыми людьми, а не предприятиями-как-машинами. Мы уже довольно эффективно учим моделировать предприятие так, чтобы поддерживать операционную работу, но дальше вопрос: а что делать после налаживания регулярного менеджмента? Собственно, непрерывно развивать и совершенствовать основные практики. И тут засада, ибо нужно возвращаться к вопросу о том, как увидеть эти предметные практики, как организовать предприятие в целом, чтобы там ещё и эти практики были, и они друг другу не мешали бы, а помогали. И тут на первый план выступает архитектура: сначала целевой системы, потом предприятия, потом цифрового двойника предприятия (то есть архитектура софта). И нужно понять предмет. Так что обсудили (список неполный, ибо сидели-то полный день с двумя кофе-брейками и обедом. Но видео, конечно, для участников группы есть):
-- архитектура как предметная область, предметы интереса архитектора, связность и зацепление (или как там это будет по русски), архитектурные стили, архитектурные решения и их оформление как архитектурные записи. Особые интересы архитектора: evolvability, transactionality.
-- безмасштабность архитектуры (у всех систем есть архитектура! все системы мы изготавливаем, значит должен быть архитектор!), зависимость одних архитектур от других (закон Конвея и обратный манёвр Конвея), наличие самых разных архитекторов в проектах и как об этом думать директору по развитию (который по большому счёту тоже архитектор)
-- о чём разговаривают архитекторы с разработчиками (и что там с линией предмета интереса, интереса, требований и решений по линии архитектора), роль это или должность, в чём там отношение governance и какое у них лидерство (собственно, тема дня: "людей нужно убалтывать выполнять их роли. Но ещё и убалтывать придерживаться архитектуры")
-- если архитектора нет, то откуда его взять (разница между архитектором и "очень опытным разработчиком": как раз отсутствие предметного мышления по специальности). Архитектор должен знать: 1. архитектуру как практику (там своя онтология, 1000 страниц учебных материалов), 2. архитектурные паттерны в целевой предметной области (собственно прикладная архитектура), в том числе знать целевую предметную область, и 3. предметную область прикладной инженерии/разработки (программной инженерии, железной инженерии и т.д., ибо ему надо governance там делать). И ещё ему нужно заниматься немного разработкой, чтобы не оторваться от реальности (если софтовая архитектура, то кодировать).
-- где почитать про современное понимание архитектуры, немного про архитектурные стили (и что такое были бы "микросервисы" в архитектуре предприятия, а не в софте: кросс-функциональные команды и bounded context).
Книжка, которая предлагает новую стадию ещё перед разработкой требований (ну, или перед разработкой организационных норм https://ailev.livejournal.com/693597.html, как мы это поняли из стандарта SBVR https://www.omg.org/spec/SBVR/, где 95% про онтологию как business vocabulary и 5% про собственно business rules), или перед любой вообще разработкой (если говорить о безмасштабности): это domain engineering. Вот из свеженького в этой области: https://b-ok.cc/book/18076916/00f053. "Domain Science and Engineering: A Foundation for Software Development". This is the first thorough monograph treatment of the new software engineering phase of software development, one that precedes requirements engineering. It emphasizes a methodological approach by treating, in depth, analysis and description principles, techniques and tools. It does this by basing its domain modeling on fundamental philosophical principles, a view that is new for a computer science monograph. Так сказать, "вот ещё один Gellish" (там и язычок онтологическй предлагается, и все проблемы использования онтологий в разработке). Автор знает слово "онтология" но предпочитает говорить domain science and engineering.
В чате блога неожиданно дискуссия о различиях программных и железных инженеров. Для меня это всё просто "инженеры" (и помним, что есть же ещё и цифровые двойники, и цепочки создания, и менеджмент, так что там всё вообще перевязано оказывается плотно). Но вопросы остаются про железных инженеров (как будто у них там "всё попроще", но нет), про программных инженеров (как будто у них не инженерия, а art и сraft, но нет) и отсутствие системного мышления у них всех -- с https://t.me/ailev_blog_discussion/15792.
Мону Лизу и Гоголя, наконец, более-менее оживили. Впрочем, более-менее оживили вообще всех, кого хочешь, но они пока не разговаривают: https://petapixel.com/2022/07/22/megaportraits-high-res-deepfakes-created-from-a-single-photo/. Начинаем жить в очень странном мире.
Вчера танцевал в шортах, очень забавно выглядит (попал на видео): https://vk.com/wall2449939_4204.
-- архитектура как предметная область, предметы интереса архитектора, связность и зацепление (или как там это будет по русски), архитектурные стили, архитектурные решения и их оформление как архитектурные записи. Особые интересы архитектора: evolvability, transactionality.
-- безмасштабность архитектуры (у всех систем есть архитектура! все системы мы изготавливаем, значит должен быть архитектор!), зависимость одних архитектур от других (закон Конвея и обратный манёвр Конвея), наличие самых разных архитекторов в проектах и как об этом думать директору по развитию (который по большому счёту тоже архитектор)
-- о чём разговаривают архитекторы с разработчиками (и что там с линией предмета интереса, интереса, требований и решений по линии архитектора), роль это или должность, в чём там отношение governance и какое у них лидерство (собственно, тема дня: "людей нужно убалтывать выполнять их роли. Но ещё и убалтывать придерживаться архитектуры")
-- если архитектора нет, то откуда его взять (разница между архитектором и "очень опытным разработчиком": как раз отсутствие предметного мышления по специальности). Архитектор должен знать: 1. архитектуру как практику (там своя онтология, 1000 страниц учебных материалов), 2. архитектурные паттерны в целевой предметной области (собственно прикладная архитектура), в том числе знать целевую предметную область, и 3. предметную область прикладной инженерии/разработки (программной инженерии, железной инженерии и т.д., ибо ему надо governance там делать). И ещё ему нужно заниматься немного разработкой, чтобы не оторваться от реальности (если софтовая архитектура, то кодировать).
-- где почитать про современное понимание архитектуры, немного про архитектурные стили (и что такое были бы "микросервисы" в архитектуре предприятия, а не в софте: кросс-функциональные команды и bounded context).
Книжка, которая предлагает новую стадию ещё перед разработкой требований (ну, или перед разработкой организационных норм https://ailev.livejournal.com/693597.html, как мы это поняли из стандарта SBVR https://www.omg.org/spec/SBVR/, где 95% про онтологию как business vocabulary и 5% про собственно business rules), или перед любой вообще разработкой (если говорить о безмасштабности): это domain engineering. Вот из свеженького в этой области: https://b-ok.cc/book/18076916/00f053. "Domain Science and Engineering: A Foundation for Software Development". This is the first thorough monograph treatment of the new software engineering phase of software development, one that precedes requirements engineering. It emphasizes a methodological approach by treating, in depth, analysis and description principles, techniques and tools. It does this by basing its domain modeling on fundamental philosophical principles, a view that is new for a computer science monograph. Так сказать, "вот ещё один Gellish" (там и язычок онтологическй предлагается, и все проблемы использования онтологий в разработке). Автор знает слово "онтология" но предпочитает говорить domain science and engineering.
В чате блога неожиданно дискуссия о различиях программных и железных инженеров. Для меня это всё просто "инженеры" (и помним, что есть же ещё и цифровые двойники, и цепочки создания, и менеджмент, так что там всё вообще перевязано оказывается плотно). Но вопросы остаются про железных инженеров (как будто у них там "всё попроще", но нет), про программных инженеров (как будто у них не инженерия, а art и сraft, но нет) и отсутствие системного мышления у них всех -- с https://t.me/ailev_blog_discussion/15792.
Мону Лизу и Гоголя, наконец, более-менее оживили. Впрочем, более-менее оживили вообще всех, кого хочешь, но они пока не разговаривают: https://petapixel.com/2022/07/22/megaportraits-high-res-deepfakes-created-from-a-single-photo/. Начинаем жить в очень странном мире.
Вчера танцевал в шортах, очень забавно выглядит (попал на видео): https://vk.com/wall2449939_4204.