Мы убеждены, что единица продуктивности это команда, а не отдельные люди. Мы видим ценность в командах и хотим предложить площадку для команд разработки.
На площадке http://topteams.ru команды публикуют контактную информацию, обезличенные резюме, портфолио, и технологии, на которых специализируются. Мы уже начали привлекать корпоративных заказчиков, которым требуются слаженные команды разработчиков. Сейчас вы можете создать профиль команды и делиться ссылкой с партнерами. Сервис TopTeams бесплатный для команд.
Будем рады видеть вас на площадке TopTeams.

На сегодня есть MVP, базовый функционал работает

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

Будем рады репостам и обратной связи. При этом мы понимаем, что решение далеко от идеала конечно.

Мы писали сервис на платформе версии X, у которой уже не выходят security issues patch'и, по хорошему надо обновиться на версию Y. 
Как это обосновать?

На сайте sei.cmu.edu есть информация по этому поводу:
https://www.google.com/search?q=risk+management+site%3Asei.cmu.edu%2F

Говорят, что есть еще хорошая книга "Just Enough Software Architecture: A Risk-Driven Approach", но я пока не имел еще возможности с ней ознакомиться - не могу ничего сказать.

Я все-таки склонен полагать, что серебрянной пули нет. Любое решение имеет свой контекст применимости. Главное, распознать ключевые драйверы, действующие на решение. Решения становятся еще более интересным в условиях, когда тактические интересы входят в противоречие со стратегическими интересами. У Гарвард Ревью есть хорошая подборка по Decision Making, тоже, пока еще не имел возможности ознакомиться, но много наслышан. Там, говорят, и про психологические ловушки хорошо пишут.

Хорошо

Если решение будет сложное, пусть будет несколько "больших" блоков, "Модульных монолитов", можно назвать их Подсистемами, Приложениями, как угодно.

Модули внутри таких Монолитов и будут кандидатами на "вынос", если им по каким-то причинам понадобится автономность

Модули можно назвать сервисами

Сервисы будут разного размера, среди них будут микро

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

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

Все это хорошо, но когда нужно вовлечь в проект сразу много человек, то нужно понимать, что кадры не смогут укомплектовать все позиции первоклассными спецами. И средний уровень дисциплины и квалификации разработчиков будет оставлять желать лучшего. И тогда поплывут ограниченные контексты очень быстро. Здесь я согласен со Stefan Tilkov:

📝 "In theory, you don’t need microservices for this if you simply have the discipline to follow clear rules and establish clear boundaries within your monolithic application; in practice, I’ve found this to be the case only very rarely.)"
- "Don’t start with a monolith" by Stefan Tilkov
https://martinfowler.com/articles/dont-start-monolith.html

Как это противоречит тому, что я сказал?

Кроме того, что Микросервисы - это миф

Оно не противоречит, а дополняет, и обращает внимание на ту причину, по которой чаще всего плывут ограниченные контексты.

Прости пожалуйста. Внимательно посмотрю

Да, ограниченные контексты плывут всегда. Именно всегда. Да, по разным причинам

В теории ты прав. Единица автономности команды - это BC, и тут неважно, состоит он из микросервиса(-ов) или нет. На практике же серьезное влияние оказывает уровень дисциплины и квалификации команд.

Согласен

Если команды слабые, они всё-равно сделают Big Ball of Mud

И в этом случае вспоминать теорию малополезно

Иногда видно, что команда может сделать только говно

То есть, иногда ситуация фатальна

Иногда достаточно посмотреть на тимлида, и станет понятно, что ситуация фатальна

Коллеги, добрый день. Подскажите пожалуйста как можно усовершенствовать и нужно ли, следующее решение по организации ролевого доступа.
Есть ряд пользовательских приложений (ПП) примерно одинакового профиля, к которым нужно дать доступ пользователям организаций. Организаций достаточно много, есть пожелание гибко управлять контролем доступа организаций к приложениям как со стороны администратора инфраструктуры, так и со стороны администраторов организаций, которые хотели бы определять права своих юзеров.  Есть приложение контроля доступа (ПКД), которое отвечает за централизованную аутентификацию и авторизацию доступа.
Предлагаемое решение для контроля доступа пользователей к функциям приложений со стороны администраторов организаций:
- Каждое приложение определяет набор функций, к которым хочет дать доступ, иногда достаточно мелких.
- ПКД  хранит данные о связи Функции Приложения - Права - Роль, предполагается что доступ всегда дается по разрешающей модели, то есть если роль пользователя включает права на функции приложения, то пользователь имеет право ими пользоваться, иначе нет.
- Пользователь может обладать одной или несколькими ролями, что позволяет варьировать уровень его доступа. Администратор по умолчанию обладает всеми ролями и таким образом полным набором прав на функции приложения.
- В случае необходимости дать избирательный доступ, можно будет назначить пользователю комбинацию из ролей и прав, или только прав, чтобы не создавать выделенные роли для частных случаев использования приложения.

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

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

Какие недостатки вы видите в предложенном решении и какие решения знаете, используете в таких случаях?

По аналогии можете рекомендовать курсы по togaf на русском языке?

Тимур, предлагаю решить экономическое уравнение — кому в 21-м году стоит делать бесплатные курсы по togaf на русском языке и какого они будут качества