📏 Стандартизация и единообразие.

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

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

- Баранов Сергей @sergey486
- Круглов Геннадий @GKruglov
- Лукьянов Евгений @elukianov
- Закревский Иван @emacsway

Почитать устав и ознакомиться с целями можно тут. По вопросам вступления обращаться в Joining Bot: @ru_arc_bot

После вчерашней новости поступило много сообщений в @ru_arc_bot. Мы всех видели, никого не потеряли, всем обязательно ответим, но чуть-чуть позже (нас завалило оргмоментами и работой). В скором времени свяжемся. Спасибо за оказаное нам доверие!)

С Днем Программиста!

Про членские взносы. Вчера часто спрашивали. Поясняю.

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

2. Размеры членских взносов устанавливают сами члены Организации на Общем собрании - это их исключительная компетенция, закрепленная ФЗ 7 и ГК. Сколько они сами решат, столько и будут платить.

Зачем мы внесли информацию о членских взносах в Устав, если их по факту нет? Изменение Устава - штука достаточно хлопотная, т.к. ГК допускает изменение Устава исключительно очной формой Общего собрания членов Организации. А это значит, что в одно время и в одном месте нужно физически собрать как минимум кворум в половину состава организации. Поэтому, ряд положений Устава был просто скопирован из типового Устава "на вырост", с целью минимизации изменений Устава.

Зачем мы формализовались?

Чтобы иметь законное право называться организацией в исполнение ФЗ 82. А для этого необходимо, чтобы организация имела Устав и Протокол учредительного собрания. С момента учреждения все учредители автоматически становятся членами организации наравне со всеми остальными членами.

Вчера прозвучало утверждение о коммерциализации нами сообщества.

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

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

В-третьих, члены Комитета и Председатель Организации находятся даже в менее выгодном положении, нежели рядовой её член или вообще случайный прохожий, потому что существует ст.27 ФЗ 7
https://www.consultant.ru/document/cons_doc_LAW_8824/1b0c2d3c7cca721994c4211fe5940aea1e16fd6d/

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

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

Зачем тогда мы сделали организацию?

Мы сделали её потому, что:

1. Нам нравится развиваться вместе. Мы знаем друг друга уже давно и взаимовыручка стала для нас привычной.

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

2. Нам нравится объединять крутых спецов и вместе достигать вершин квалификации.

За короткое время существования объединения я обрел невероятно качественный и чрезвычайно востребованный инкремент знаний. В одиночку я этого не сделал бы никогда. Никакие платные курсы с этим не могут сравниться.

3. Мы видим ряд проблем в отрасли, устранить которые в одиночку невозможно. Но если консолидировать усилия, то расстановка действующих сил изменится.

Нам нравится качественно изменять условия своей работы. Мне объединение уже изменило условия моей работы информационно, методически и имиджево. Мы провели совместную конференцию, сделали workshop для программистов по EventStorming, получили ряд первоклассных консультаций известных узкопрофильных специалистов по трудным вопросам, приняли участие в подготовке к печати книги "Learning DDD" - фамилии наших сотрудников отражены на странице Acknowledgments.

4. Нам нравится быть организованной силой, которая стоит на защите наших общих интересов.

5. См. #Goal и уставные цели, которые были сформированы на основе коллегиального анализа проблематики отрасли.

Если вы разделяете нашу позицию, то Закон предусматривает два вида участия в организации:

1. членство и почетное членство;
2. участие и почетное участие.

Членство подразумевает под собой признание уставных целей и принятие на себя прав и обязанностей. Только члены Организации могут определять способы её существования.

Участие подразумевает просто признание уставных целей и способствование их достижению. Никак не оформляется, ни к чему не обязывает, но и прав никаких не дает.

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

Членство в организации возможно только по рекомендации действующего её члена со стажем не менее полугода или с момента учреждения организации. Если рекомендовать некому, то можно обратиться в бот @ru_arc_bot, и в процессе участия в деятельности организации появится возможность заручиться рекомендацией.

Для подписчиков канала скидка 20% на конференцию ArchDays по промокоду ru_arc

https://archconf.ru/welcome_from_sergey

Уже принято 20 выступлений, в этом году усилилась сходимость к миссии, которую я ставил перед конференцией:
«распространение имеющихся и создание новых знаний об архитектуре программных решений».

О системе квалификационной классификации. Зачем и почему она была создана.

1. Мы не первые, кто осознал в ней необходимость и предпринял попытку реализовать её. Похожая система существует во многих объединениях, например, в проектной ассоциации:
- https://projects.management/infopage.html?Page=vision
- https://projects.management/infopage.html?Page=statuses

Большую популярность набирают социальные токены.

Даже в LinkedIn есть система Endorsement.

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

Насколько нам это удалось - будем смотреть на практике и адаптировать по результату.

Исходный код разрабатываемой системы открыт:
- https://github.com/emacsway/grade

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

3. Еще Gregor Hohpe подсветил ключевую проблему экспертных сообществ - Эффект Даннинга-Крюгера, по причине которого генерируется большое количество информационных помех в сообществе, что повышает когнитивную нагрузку на участников сообщества и демотивирует грамотных экспертов. Система призвана восстановить качество информационного пространства.

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

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

4. Закон не позволяет принимать решения по самоуправлению дифференцировано, но предусматривает возможность создания добровольных совещательных органов. Разные люди обладают разным уровнем экспертности, игнорирование которого не позволило бы максимально полно отразить экспертность в рекомендациях совещательного органа.

5. Система banofbot сообщества очень примитивна и рискованна. Её можно усовершенствовать, если учитывать ценность вклада и экспертность того, кто банит, и того, кого банят. Таким образом можно существенно облегчить бан спамеров и защититься от атак против весомых участников чата.

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

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

💬 "I’ve always been puzzled why the balance between structure & behavior investment seems so hard to maintain. I’m also puzzled why the balance we see in the wild is so heavily tilted towards behavior changes when as I geek I think it should be more balanced.

If "behavior change = revenue" & "structure change = option", then the struggle for balance makes more sense. It’s not about the personalities of Product versus Engineering. It’s not about short-sighted versus visionary thinking. The struggle is economic—do we make some money now or more money later? The answer is always “both”. We have to make some money now to survive. We want to make more money later. Fear versus greed. No wonder it’s so hard to get time to refactor."

— "Behavior Change = Revenue Versus Structure Change = Option" by Kent Beck

Эта картинка прекрасна. В ней есть источник света (ученье - свет), передовые средства навигации (облегчение навигации в обширной области знаний - одна из ключевых наших целей) и сама необъятность просторов.

Ну и центр притяжения Земли, обеспечивающий орбиту своих спутников - роль которого и должно выполнить наше объединение 🙂))

🔷 "Event Sourcing explained" - The internet contains many confusing articles that mix Event Sourcing with EDA and CQRS. Let’s see what it is and what not.
by Anton Stöckl - автор проекта go-iddd - Golang DDD CQRS/ES Reference Application

#DDD #EDA #CQRS #EventSourcing #SoftwareDesign

🔷 "Using scenarios to reinvigorate your microservice architecture" by Chris Richardson

It sounds dull but good architecture documentation is essential. Especially when you are actively trying to improve your architecture. For example, I spend a lot time helping clients modernize their software architecture. Yet more often than I like, I’m presented with a vague and lifeless collection of boxes and lines. As a result, it’s sometimes difficult to discuss the architecture in a meaningful and productive way.

In this presentation, I’ll describe techniques for creating minimal yet effective documentation for your application’s microservice architecture. In particular, you will learn how documenting scenarios can bring your architecture to life.

#Microservices #Documenting #SoftwareArchitecture

🔷 "The Process Automation Map" by Bernd Reucker
🔷 "Exploring the Process Automation Map" by Bernd Reucker
Как раз недавно поднимался вопрос по этой теме в чате канала.

#SoftwareArchitecture

🔷 "Concerned about Serverless Lock-in? Consider Patterns!" by Gregor Hohpe

Design patterns have long been a useful tool for designing software. Several decades later, they can do magic for your solutions by not only improving your designs but also by reducing switching costs.

#SoftwareArchitecture #DistributedSystems

🔷 "10 problems that Event Sourcing can help solve for you" by Dennis Doomen

#DDD #CQRS #EventSourcing #SoftwareDesign

Интересное ежегодное исследование от компании Positive Technologies в мире информационной безопасности.
Тренды, аналитика, события. Отвлекитесь и полистайте на выходных =)
https://www.ptsecurity.com/ru-ru/research/analytics/positive-research-2022/

Software engineering and systems engineering - связь этих дисциплин и стандарт The Software Engineering Body of Knowledge

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

"Software engineering and systems engineering are not merely related disciplines; they are intimately intertwined. (See Systems Engineering and Other Disciplines.) Good systems engineering is a key factor in enabling good software engineering.

The SEBoK explicitly recognizes and embraces the intertwining between systems engineering and software engineering, as well as defining the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK) (Bourque, and Fairley 2014)."
https://www.sebokwiki.org/wiki/Systems_Engineering_and_Software_Engineering

SWEBOK - это стандарт
ISO/IEC TR 19759:2015
Software Engineering — Guide to the software engineering body of knowledge (SWEBOK): https://www.iso.org/standard/67604.html

Здесь обзор текущей версии SWEBOK (v3): https://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide#Knowledge_Areas_Characterizing_the_Practice_of_Software_Engineering

А здесь можно скачать SWEBOK v3:
https://www.computer.org/education/bodies-of-knowledge/software-engineering

А вот здесь SWEBOK v3 на русском: https://github.com/ligurio/swebok-2004-in-russian

Драфт новой версии SWEBOK (v4): https://waseda.app.box.com/v/ieee-cs-swebok