Архитектура ИТ-решений
13.5K subscribers
273 photos
27 files
1.08K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Этот канал не продается, а я не сдаю квартиры/машины/яхты. Будьте, пожалуйста, осторожны!
Download Telegram
Всем привет! Обычно я так не делаю, но для следующего вебинара, который случится в первой половине июля, хочу провести голосование по выбору темы. Какая окажется наиболее востребованной, ту и обсудим. (Уточняющие вопросы, а также рекомендации по темам приветствуются в группе этого канала)
Более половины высказались за Дилемму корпоративного ИТ-архитектора Спасибо. Так тому и быть. Ссылка на предстоящую трансляцию: https://youtu.be/XVkExnJ6lrw
Forwarded from Дарья Кафтан
Коллеги, в этот четверг в 20:00 состоится доклад Алексея Сенькова
"Классификация видов долга, накапливающегося со стороны разработки"

Аннотация
:
Часто на конференциях по разработке ПО проскальзывает термин "технический долг", иногда рядом с ним появляется "архитектурный долг". Но никто явно не говорит об "организационном долге" - понимании необходимости развития процессов разработки ПО, которые были отложены ввиду каких-то причин.
Вопросы для обсуждения:
1. Выделение типов долга. Какие типы долга известны? Можно ли выделить можно ли выделить отдельно архитектурный долг?
2. Организационный долг. Формирование понятия о тех долге, обстоятельствах возникновения и рисках (риски несомненно не менее высоки чем риски, связанные с техническим долгом). ЖЦ организационного долга. Виды орг. долга, возникающие на различных этапах развития команды разработки.
Форма доклада: дискуссия
Продолжительность доклада: 15-20 мин презентация + время на обсуждение.
Ссылка на конференцию zoom:
https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09
Идентификатор конференции: 890 1916 0706
Пароль: 513901
Хочу такой :-0
Forwarded from Дарья Кафтан
Коллеги, в четверг 02.07.2020 в 20:00 в zoom состоится доклад Александра Самарина
"ISO/IEC/IEEE 42010:2011 viewpoints, views, model-kinds and models for Enterprise Architecture (Smart Cities as an example)"

Аннотация
:
При построении Умных Городов (УГ) необходимо решать одновременно несколько известных задачек:
1) зная, что решения УГ примерно на 70 % одинаковы во всех УГ как избежать «изобретения велосипедов» в разных городах.
2) зная, что в разных городах будут работать разные команды, как достичь того, чтобы решения, сделанные в одном городе, можно было бы использовать в других городах.
3) зная, что бюджеты на УГ весьма ограничены, как сделать построение УГ доходной программой.
Форма доклада: презентация
Продолжительность доклада: 25 мин + дискуссия
Ссылка на конференцию:
https://us02web.zoom.us/j/82504629520?pwd=VmNIOTRkSlh1ejMzNjQzWE1hRUZFZz09
Идентификатор конференции: 825 0462 9520 Пароль: 029023
Похоже, что AWS появится в России и случится это через Mail.ru. Комментарии экспертов в статье экспертностью не блещут (ага, мультиклауд, вот именно его и не хватает нынче отечественным заказчикам), но если AWS здесь появится, хотя бы с основными своими сервисами, то изучать ИТ-архитектуру мы будем именно по ним https://www.kommersant.ru/doc/4405864
Да, и локальные сервисы станут резко потерять свою актуальность... Тарантул, говорите, ага, щас!
Forwarded from Дарья Кафтан
Коллеги, в четверг 09.07.2020 в 20:00 MSK в zoom состоится доклад Геннадия Круглова
"Трансформация роли архитектора в технологического партнёра бизнеса (сейлов, топов, лпр)"

Аннотация:
В процессе работы над архитектурными решениями стало понятно, что становится востребованной роль некоего партнёра для нетехнических ЛПР:
1) ЛПР нужно слушать (общаться) на постоянной основе, чтобы помогать структурировать мысли и проецировать их на технические решения, буквально проводить оценку в реальном времени их реализуемости, порядка трудозатрат и расширять, трансформировать идеи.
2) Проводить «мягкое» обучение в процессе общения по технологиям, арх. и орг. подходам, для чтобы ЛПР трезво оценивали их возможности и ограничения.
3) Быстро предлагать концепты, то есть делать высокоуровневый системный дизайн для поддержки продаж.
4) По их просьбе проводить аудит архитектуры и процессов разработки в проектах, выдавать заключения и рекомендации.
Хотелось бы рассказать об этом и о том, какие возникают сложности при взаимодействии и какие навыки нужно совершенствовать.

Форма доклада: презентация + обсуждение
Продолжительность доклада: 30 минут доклад, ~30 минут обсуждение
Ссылка на конференцию: Ссылка на конференцию:
https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09
Идентификатор конференции: 890 1916 0706 Пароль: 513901
Как понять, что вы разговариваете с настоящим ИТ-архитектором https://mxsmirnov.com/2020/07/07/real-architect/
Слайды сегодняшнего вебинара здесь: https://drive.google.com/file/d/19zdMzBfhjtN0VIHhApXt1XjM6M1aEp07/view?usp=sharing Запись получилась (ну, если не считать обрезки по правому краю :), см. там же: https://youtu.be/XVkExnJ6lrw Вопросы и комментарии пишите в группу канала https://tttttt.me/joinchat/DOGCZU3C1uO5I9zWYGcLfg
Пятничное: почему такой живой и неутихающий интерес вызывает вопрос: должен ли ИТ-архитектор писать код? Давайте пойдем дальше и спросим себя: а не должен ли архитектор исполнять код? Почему бы и нет. Представить себя процессором или виртуальной java-машиной. Взять листочек бумажки в клеточку для записи значений переменных, карандаш, ластик. Отчеркнуть в сторонке область для стека вызовов. Попросить коллегу громко произнести F5 и вперед, поехали, так сказать
Наверное, это самый интересный слайд прошедшего вебинара (Ссылка на запись: https://youtu.be/XVkExnJ6lrw?t=3274)
Forwarded from Дарья Кафтан
Коллеги, в четверг 16.07.2020 в 20:00MSK в zoom состоится доклад Александра Лучкова
"Непрерывное применение архитектурных практик как способ снижения рисков"

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

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

В рамках доклада я попробую обосновать свою точку зрения на причины возникновения подобных суждений, некоторые их риски и пути устранения этих рисков в духе применения принципов непрерывного приращения ценности результатов труда.
Продолжительность доклада: ~45 минут доклад, ~30 минут обсуждение
Ссылка на конференцию: https://us02web.zoom.us/j/89019160706?pwd=dXF2ZFVFUWh2NDUwbTlaMFM3M09Xdz09
Идентификатор конференции: 890 1916 0706
Пароль: 513901
The code is the truth, but not the whole truth
https://twitter.com/Grady_Booch/status/1278949993722724352
Великие архитекторы тоже любят пообсуждать вечные темы нашего архитектурного чатика: https://tttttt.me/itarchitect :-)