0: Здравствуйте, коллеги. Спасибо всем, что кто присоединился сегодня. У нас открытый урок по его теме. Архитектура корпорации итогов 10 и 1 фаза цикла айдиэм.

1: Это архитектурное видение.

2: Денис, меня зовут, я являюсь 1 из преподавателей курса архитектуры корпорации Токов 10, и у меня есть некий продолжительный опыт в разработке и

3: Тема устройств для иностранных компаний, в том числе я около 8 лет дополнительно работал в Роли главного архитектора проектов и какое-то время в Роли корпоративного архитектора различных компаний.

4: Поэтому у меня есть теоретические и практические знания в том в тех вопросах, которые преподаются на курсе и в части архитектуры систем или design system тоже, поэтому можно обращаться.

5: У нас есть правила вебинара, они достаточно дружелюбные, свободные чат. Это наша форма общения с вами. Не стесняйтесь писать туда вопросы чат я вижу сразу, могу не ответить. Можем потом.

6: Смотреть. У нас в конце останется какое-то время для свободной беседы. Готовьте свои вопросы. Материал у нас сегодня он, казалось бы, с 1 стороны, может быть немножко теоретизированный, но имеет большую практическую ценность. Плюс я всегда 100.

7: Стараюсь приводить материал к практическим, к практической части и к тому, как его в реальности использовать, а также делюсь опытом использования, который я применяю в своих проектах.

8: О чем сегодня будем разговаривать? Сегодня будем сегодня поговорим немножко о том, что такое отус и как, какие курсы, и что в этой компании есть. Посмотрим немножко поговорим о том, что такое тогов, и

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

10: Немножко поговорим о такой весёлой теме, как вот то, что изучается на курсах корпоративной архитектуры, совмещается с принципами agile и вообще может ли это быть применимо?

11: И как потом мы поговорим немножко о тех программах обучения, которые на курсе есть, и в свободной форме пообщаемся.

12: Пока у нас слушатели подключаются, напишите немножко в чат о себе, может быть каких-то пару слов. С какой целью записались на занятия? Хотели

13: Либо посещать занятия того по opus, по теме тогов, или по каким-то любым, или по каким-то другим темам. Может быть, какой-то вопрос уже назрел и готовы его обсудить. Вот пару минут, минуты, 2.

14: 3. Подождём, пока остальные подключаются, и тогда продолжим. Пока не стесняйтесь, пишите, может быть, какой-то вопрос есть.

15: Так, ну вы пока пишите, а я расскажу о том, что такое отус. Отус. Это компания, которая прежде всего имеет образовательную лицензию государственного образца и после окончания курсов на о.

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

17: Онлайн курсы, на которые я сходил, они имеют всю силу. Кроме того, отус создаёт свои авторские онлайн курсы.

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

19: Занятий, наверное, или ближе к концу. Мы, я попрошу вас заполнить, пройти по ссылке, заполнить опросник. Будем очень благодарны за обратную связь по занятию. Какие направления у курсов есть? Ну, это

20: Базовые направления, которые актуальны сегодня, всего, более всего у отуса около 130 курсов и больше они охватывают практически все направления. То есть это программирование, инфраструктура.

21: Тестирование аналитика модный сегодня data science биг дата есть курсы по информационной безопасности есть вот курсы по архитектуре, есть по highload хайлоуд системам и прочему курсы все интересные, насыщенные.

22: Занятия, например, которые веду я, они всегда на практику.

23: Они всегда нацелены на практику.

24: Так, смотрю, подтягиваются, подтягиваются. Итак, давайте перейдём немножко к нашему основному занятию.

25: Какие, что на занятии. Мы сегодня постараемся узнать, какие вопросы затронуть вообще мы поговорим в целом, что такое архитектурный вижн и какова его роль. Забегая вперёд, скажу, что это 1 из

26: Важнейший, 1 из важнейших этапов всего архитектурного цикла, да, как нам определить, что мы достигли понимания и успехов в занятиях? Это то, что мы поймём?

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

28: В вижене. Посмотрим его на практике. Поймём, как посмотреть, готов ли бизнес трансформации и кто такие заинтересованные стороны или стейкхолдеры, как их определить и самое главное, зачем.

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

30: Кто знаком, значит, может быть, для себя найдёт что-то новое, кто не знаком, я вкратце расскажу. Значит, что такое тогов сам по себе тогов это так называемый архитектурный фреймворк для упра.

31: Управление корпоративной архитектурой, управление изменениями и развитием. Прежде всего это фреймворк, то есть он состоит условно из 2 слов, это frame и work, то есть работа в рамках, он определяет те рамки и те подходы, которые

32: Который должен использовать архитектор в своей работе на любом уровне, будь то это корпоративный архитектор, архитектор управления, системный или solution, или любой или бизнес архитектор, но для бизнес архитектуры итогов существует отдельный специальный разде.

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

34: Скажем так, зафиксированные, задокументированные в определённом формате практики, наработанные большим количеством конструкторов, дизайнеров, архитекторов, систем, с тем, чтобы систематизировать свои зна,

35: Развивать их и смотреть, и наблюдать за изменениями, определять, в том ли направлении идёт архитектура или нет.

36: Конечно, он развивается и претерпевает изменения. То есть сейчас уже существует 10 версия. Примерно раз в 2, в 3 года выходит ревью, может быть 4. Здесь, конечно, чёткого расписания нет, потому что это все-таки

37: Скажем так, открытая группа взаимодействия. То есть, да, скажем так, это не является ежедневной профессиональной деятельностью, да, но, тем не менее, стараются её поддерживать, как вы понимаете, даже опенсорс

38: Который начинался среди любителей, сейчас перешёл в довольно-таки профессиональную стадию и является уже направлением деятельности. Вот он происходит ревью. Сейчас 10 версия и тогов тем не менее,

39: Вопреки желанию назвать его каким-то там устаревшим. И нам там корпоративная архитектура сегодня не нужна. И вообще все эти архитектурные подходы не нужны. Тем не менее, даже имеет open эджайл, архитектор фреймворк. Для то,

40: Того, что который в явном виде показывает какие архитектурные подходы в agile методология существуют и как они переплетаются и мы кстати на примере вижена посмотрим сегодня как vision в конце будет как vision отвечает

41: На 12 постулатов оджал манифесто. И почему он актуален, что хочется ещё добавить? Нет, добавлю потом немножко формальности тогов стоит на

42: 4 столпах или на 4 слоях. Это бизнес данные приложения и технологии. Ну или технологии приложения. Тут зависит от того, что как идёт

43: Самое интересное, что наиболее важными слоями здесь являются бизнес и данные, это немножко

44: Не совпадает с тем подходом, который мы привыкли видеть в ежедневной своей работе, потому что мы в массе прикладники. И когда к нам приходят с задачей, мы сразу смотрим, а как бы её, ну, условно,

45: Разработать и где её разместить, как стартануть, где там она в контейнерах, не в контейнерах будет, в кубернетесе или на виртуалках. Вот кубернетос и виртуалки это технологическая архитектура, как вы понимаете.

46: Архитектура приложения это модули, компоненты взаимосвязи, но начинать все нужно с бизнес процесса и архитектуры данных, и

47: Так или иначе, все стадии архитектурного цикла, которые мы посмотрим на следующем слайде проходят все, все, все разработчики и все группы разработки, даже если они их не определяют и даже если они их в явном виде не выделяют и не видят,

48: И даже если архитектурная функция у них в принципе не выделена в отдельную роль и размазана между всеми участниками, я сейчас

49: Это объясню. Ну, можем, можем подискутировать немножко. Вот. Но главное, запом, запомнить, что того стоит на 4, на 4 слоях. Это бизнес данные, приложение и технологии, ну, или технологии приложения. Кому как.

50: Здесь не принципиально. Вот почему, почему идёт 1 бизнес, потом данные, потому что с точки зрения бизнеса мы реализуем бизнес процессы с точки зрения данных, это то, через что эти

51: Это то, через что эти бизнес процессы реализуются. В любом случае вы реализуете через данные, через движение, модификацию, создание, уничтожение и реализацию жизни цикла данных, навер,

52: Есть случаи, когда данные не так важны, но прям вот из головы вспомнить их не могу. То есть 99% случаев архитектурных задач, которые решаются, они решаются через данные. У меня есть отдельный курс.

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

54: Произошло такое изменение буквально недавно, ну лет 5, может быть 7, может 8 назад, когда big data вошла как в свою свою силу, то есть нельзя сказать, что она в зрелости ещё, но это уже не ребёнок.

55: Что она вошла в свою силу, это, скажем так, такой крепкий подросток и is биг даты выросли, выросли дейта дривн компании, то есть для которых данные это есть.

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

57: Ну перейдём непосредственно к значит dm это знаменитая кто не знает кто не видел, это знаменитая ромашка тогов да, в которой значит есть.

58: 8 этапов это если идти от начинается все у нас вот отсюда, с так называемого архитектурного заказа. То есть это запрос на архитектурную

59: Вот это архитектурный заказ, да, здесь у нас определяется, и мы потом переходим в vision через вижн, мы определяем то, что должно быть сделано, и то, как оно идеально должно выглядеть. То есть мы фактически

60: Лизируем, систематизируем, визуализируем те требования, которые были сформированы в архитектурном заказе. И мы идём дальше вот в этом направлении. Здесь просто стрелочки не указаны. Мы идём дальше в этом направлении и из вижена

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

62: Вот гэп анализ у нас происходит, а вот здесь у нас происходит, здесь у нас происходит внедрение

63: А вот здесь у нас происходит ревью того, что сделано, и цикл возвращается, возвращается обратно.

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

65: Проектов также у нас формируется, финализируется

66: Финализируется запрос на архитектурную работу. То есть, как я уже сказал, это реальная формализация требований непосредственно к реализации, да, на бизнесовой части. У нас возможно какое-то ревью ролей, каких-то возможностей ещё

67: Чего-либо части приложений, данных у нас формируется

68: Диаграммы приложений это различные и архитектуры и в части технологии, это deployment, диаграммы и размещение. А дальше идёт анализ того, все ли, все ли хорошо, как нам надо перейти, куда

69: И дальше уже внедрение и

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

71: Это кладём в требования у нас здесь по центру управления требованиями. Потом мы через требования переходим в бизнес архитектуру, создав бизнес архитектуру, мы её также фиксируем в требованиях, переходим в архитектуру приложений, возвращаемся её в требования. И вот

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

73: Делать ревью, и это происходит на любой стадии.

74: Планирование и внедрение изменений организации даже внутри маленьких команд разработки. Так или иначе, даже если у вас состоит команда разработки из 2 3 человек, вы все равно проходите весь

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

76: В любом виде, будь то корпоративная архитектура, архитектура технологическая.

77: Инфраструктурная архитектуры иб и прочее, прочее. Просто у нас в явном виде мы не фиксируем себе вот, вот эти стадии, мы их не фиксируем. Да, мы сразу, вот у нас приходит задача вот сюда, в наш метод работы, и мы сразу

78: Как бы вот сюда перебегаем как мы будем её в приложениях работать, но подумав как мы её будем обрабатывать в приложении и как мы её будем размещать мы понимаем что у нас существуют какие-то недостатки то есть мы как бы формально переходим в gap анализ.

79: Но потом мы раз и возвращаемся вот сюда, а что же мы с точки зрения бизнеса делаем? Вот, потом мы ещё раз проходим по кругу приложение технологии гэп анализа, можем ещё раз вернуться, понимаете? И потом все равно

80: Мы переходим к тому, как мы переходим к целевой архитектуре и потом смотрим, что сделано и что не сделано. Вот. То есть эти стадии проходятся всеми, даже если они не выделены.

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

82: Если хотите, в конце можете накидаем примеров посмотрим, но это протограф и про архитектор девелопмент, метод, который в реальности отображает то как все работают.

83: Идём дальше. Что такое архитектурный процесс и какой вообще смысл интерпрайс архитектуры, да и архитектуры в целом в этом процессе, значит, архитектурный процесс.

84: Правильно выстроенный архитектурный процесс, он разрешает движение вот только по этим зелёным стрелочкам.

85: Бизнес. То есть у нас идёт 1 слой. У нас бизнес бизнес отправляет на другие слои запрос с вопросом, что

86: А слои отвечают бизнесу, как они это будут делать?

87: Нужно стараться избегать того, чтобы бизнес рассказывал слоям ниже, как они это будут делать, а слои ниже указывали бизнесу на то, что ему нужно делать. Вот вот правильно выстроенная архитек.

88: И чем занимается корпоративная архитектура и архитектура вообще, она, собственно, следит за тем, чтобы этот процесс выполнялся Ровно так и никак иначе. Иначе у нас начинается переплетение между между бизнесом и

89: И реализация между всеми этими слоями. И в конечном итоге начинается хождение по кругу без какого-либо видимого или значимого результата. Вот.

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

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

92: Архитектура данных отвечает на вопрос, как она это будет делать. То есть это хранилище файлов. Нужно условно, архитектура приложения определяет сервисы, которые будут обеспечивать это архитектур, технологическая архитектура определяет, ну, инфраструктурные

93: Компоненты, которые будут размещать эти сервисы, да, то есть, ну, кубернетс, например, сегодня, но

94: Нельзя, чтобы какой-то из слоёв ответил бизнесу тебе не нужны эти файлы.

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

96: Об этом можем поговорить в конце. Это было такое небольшое введение, чтобы лучше понимать, для чего нам нужен вижн, потому что мы будем много разговаривать о требованиях, о заинтересованных сторонах и прочем прочем.

97: Давайте проверим себя немножечко, как мы закончили, как мы прошли это для разминки и напишем все-таки, что такое тогов своими словами и какая роль ad, на ваш взгляд?

98: На ваш взгляд, нужна? Вот можно писать ответ, а я пока почитаю вопросы, которые тут появились.

99: Применимо ли архитекторами иб при разработке систем защиты инфраструктуры? Да, конечно, потому что разработка систем защиты инфраструктуры ничем не отличается от разработки других систем. Там только требования

100: Ну, ну и Ровно там же можно выделить и функции, сервисные функции, бизнес функции и

101: Между между сервисными бизнес сервисами и бизнес функциями всегда можно сделать связь там Ровно также есть программный слой слой данных и slow технологический Ровно также есть gap анализ Ровно, также есть переходные архитектуры, целевые.

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

103: Перейдём к основной теме. Что такое архитектурный вижн? Как и для чего архитектурный вижн, как видно на схеме? Это, соответственно, 1 шаг после получения архитектурного заказа. Да что такое вижн вижн? Это

104: Скажем так, ну мне слово целевое не нравится, конечное или желаемое видение тех изменений, которые должны возникнуть. То есть vision отражает и всего, что с этим связано, какая

105: Цель вижена это предоставить заинтересованным сторонам представление о том результате и тех изменениях, и том, и влиянии этих изменений, которые возникнут в результате реализации целевой архитектуры, или конечной архитектуры, или идеаль.

106: Архитектуры, как желаете? Также вижн может содержать переходные архитектуры, потому что не все, не все.

107: Изменение можно сделать в 1 шаг. Возможно, потребуется несколько Шагов и vision как раз это фиксируют в явном виде, указывая на

108: То, что не может быть реализовано за 1 шаг детализация виженов может быть разного уровня, однако не стоит увлекаться чрезмерной детализацией, потому что, как мы видим, у нас есть стадии б. Ц и д. Где можно детализацию увели.

109: Не нужно затягивать стадию этого вижн. Вот дальше пойдём.

110: Понятно, что visions это документ, некий его формат весьма свободен, однако есть моменты, которые в нём должны быть обязательно отражены организации, когда

111: Внедряют такую практику, они определяют, конечно, формат этого документа, он весьма различен, но все организации едины в том, что основные моменты в этом документе присутствуют, а именно это

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

113: Отображение бизнес процессов, отображение изменения данных, информационные структуры данных.

114: Необходимые переходные непосредственно архитектурные схемы, переходные архитектурные схемы.

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

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

117: Тура решения или архитектуры системы. Если говорить более привычно, в результате него рождается такой документ, да, пример есть, я заполненного нет, я покажу шаблон попозже и

118: И собирая требования для вижена, вы формируете непосредственно от архитектуры, системы архитектуры, решения, но она почему называется на этом этапе? Называется она черновиком, потому что, как я уже говорил, у нас есть этапы вот, вот эти

119: Вот б ц и д. Вот тут она уточняется здесь только намётки, только намётки, концепт.

120: Да, здесь только концепт, только намётки, но уточнение на следующих этапах какой, какая архитектурная роль должна создавать вижн, на самом деле та роль, которой пришла эта задача, можно ли привлечь архитектора более высокого и низкого уровня?

121: Более высокого, да, более низкого не очень, потому что с более низким уровнем архитектора будете. Взаимодействие будет на вот более поздних этапах, на б, ц или д, то есть, условно, архитектор системы, с ним взаимодействие будет на более позднем этапе, на этапе ц,

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

123: Нужно указывать влияние на все системы компании в целом, да, ну, тогов использует понятие корпорации, ну, может, можем использовать компании, вот. И лучше консультироваться с

124: Архитекторами более высоких уровней, у них могут быть свои дополнительные требования. Кстати, их требования, они тоже попадают в раздел требований, которые

125: В вижене должны быть отображены, в частности, в тех шаблонах, которые я использую. Есть раздел принятые архитектурные решения, и там они прям отображаются. И указывается, на какой раздел документа они влияют. Вот.

126: Соответственно, что описывается в драфте, потом архитектурного шаблона, это бизнес модели, модели данных, архитектура, приложения технологий и прочего, прочего. Да, они могут на этапе вижн быть заполнены, но не обязательно детализированы.

127: В соответствии указывается соответствие стандартам, указывается ещё что-то и переходные процессы тоже указываются. Вот, ну такой состав.

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

129: А разработка вижена у нас происходит вот здесь.

130: Вот в этом прямоугольнике, а это результат.

131: Это результат. Здесь у нас вот отмечены бизнес бизнес, драйверы, бизнесовая часть, то есть это драйверы, цели.

132: Цели и бизнес принципы, они тоже являются входными параметрами для разработки, для разработки вижена. Что такое бизнес принципы, цели и драйверы, значит,

133: Это то, что непосредственно, скажем так, заставляет реализовывать бизнес решения. Цели. Это цели, которых надо достичь. Это понятно. А что такое бизнес принцип, бизнес принципы, например, что мы не используем коробочное по или мы не исполь.

134: Коробочные системы или наоборот, мы используем только коробочные системы. Это 1 из 1 из бизнес принципов. Дак пример драйвера приведу попозже. Вот.

135: Ну, например, необходимость расширения 1 из бизнес драйверов, это может быть увеличение числа клиентов.

136: Ну, как так или, или наоборот, уменьшение, да, то есть нам от чего-то надо избавиться. Импортозамещение тоже может быть 1 из бизнес драйверов. Вот, соответственно, непосредственно у нас здесь отображён запрос на архитектур.

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

138: Выражена не все, не везде есть. Поэтому для кого-то может быть непривычно. Я опять же скажу, она есть, просто она не отражена, вы о ней просто помните и все время держите её в голове или

139: Советуйтесь, но это не значит, что её нет. Да, также архитектурные принципы вот здесь у нас отражены. Это фреймворки и архитектурные принципы. Что такое архитектурные принципы тогов, конечно, это рассказ.

140: Через очень абстрактную концепцию abb и sbb архитектур билдинг блоков и solution билдинг блоков да, но архитектурный принцип это в основном то, чем корпоративная архитектура занимается, она устанавливает критичность систем, степень

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

142: Если организация работает с входящими данными из интернета условно, то требования безопасности могут обязать организовывать дмт области как сетевые.

143: Так, и приложений. И это может быть 1 из архитектурных принципов. Или же выход в интернет для определённых систем, для систем, допустим, мишн критикал.

144: Может быть, или для систем, работающих с персональными данными, может быть организован только через специальные контуры сетевые и программные. Та же самая гарда, которые будут контролировать, чтобы лишние данные не уходили. Это тоже

145: И при разработке вижена нужно будет это учитывать. То есть это у нас является входящими вопросами.

146: В вижене мы также определяем заинтересованные стороны, то есть так называемые стейкхолдеры. Мы определяем бизнес цели и смотрим каждый раз, как vision соответствует этим бизнес целям.

147: Оценки возможностей, которые у нас есть, апп, готовность бизнеса к трансформации, например, нужно учитывать

148: Явный пример, что нам надо горизонтально масштабироваться. У нас монолитные системы, ну или же у нас не филиальная сеть, а требуется филиальная сеть, но мы сейчас, мы сейчас не готовы трансформироваться в филиальную сеть, да, поэтому

149: Vision, например, который будет подразумевать под собой филиальную сеть, не пойдёт, не ответит, скажем так, полностью на запрос архитектурной работы, принципы разработки архитектуры. Ну я уже сказал, то есть это непосредственно архитектурная схем.

150: Диаграмма, определение показателей эффективности ценности и

151: Здесь указано разработка технического задания на архитектурные работы, но по факту это и есть архитектурный драфт архитектурного решения, да.

152: Вот. Ну, а результатами мы уже их упоминали, это результатами является 1 или несколько документов. Ну вот, то есть вот здесь вот указано, да, вот у нас указаны вот эти вот

153: Свои. Это может быть 1 или несколько документов по разному организовано. Зависит от того, насколько детально организация у вас хочет видеть эти документы. Есть организации, в которых архитектурный подход, ну, тогов или иной другой.

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

155: Отдельно публиковать, отдельно согласовывать или план безопасности. План обеспечения непрерывности может быть тоже отдельным документом, а может и не быть. Поэтому это все зависит от того, насколько архитектурный метод внедрён и насколько он применяя

156: Вот что работа со стейкхолдерами. Кто такие стейкхолдеры? Это заинтересованные стороны. В широком смысле это может быть кто угодно. Это не обязательно владельцы предприятия, это не обяза.

157: Обязательно директора и не обязательно лидеры. Это может быть смежные подразделения. Это могут быть внешние подрядчики. Это могут быть регулирующие органы в зависимости от того, чем организация занимается. Факт, что от них

158: Поступают запросы и требования, и vision должен соответствовать этим запросам и требованиям. И 1 и важнейшая коммуникация, которая ведётся со стейкхолдерами. Это объяснение стейкхолдерам, как их, как vision решает их задачи. Вот в этом

159: Смысл, то есть вы делаете, делаете вижн и объясняете им, что вот была задача такая, она решается вот так через год такие изменения, вот такие у нас ограничения есть вот такие вопросы, которые нужно дополнительно осветить. Вот

160: Или же невозможность реализации таким путём, и, скорее всего, бизнес требование может быть пересмотрено на этом этапе на дальнейших этапах бизнес требования пересматривать не совсем имеет.

161: Да, vision это кстати тот этап, когда бизнес требования можно ещё пересмотреть, постараться. Ну то есть например сразу видно, что условно пожелания бизнеса требует, допустим,

162: Внедрение собственного колл центра и системы управления колл центрами, да, а это бизнес к этому не готов. И на этапе вижена. То есть вы делаете вижн небольшой, на котором условно, в центре

163: Рисуете колл центр и расписываете его функции, ну там приём звонков, ответ и прочее. Вот. И говорите. Вот смотрите, вот ваши требования через колл центр реализуются.

164: Бизнес такой думает, что да, че то мы не готовы, давайте мы просто поставим, посадим сколько-то там секретарей, пусть они отвечают ну как-то так или же бизнес говорит, что я хочу абсолютную надёжность, то есть rp оо 0 рпио 0.

165: Это, а у него, например, системы такие, которые не могут это обеспечить. И для этого надо дополнительные какие-то решения придумать, которые, например, дорогостоящие или, например, не существует технологии, которая, например, вот url не может

166: Больше чем на 1650 километров между 2 узлами. Обеспечить связь вообще никак. Это тоже может быть ограничением, а данные нужно передавать, например, как они хотят на большее расстояние. Поэтому

167: Это тот момент, когда можно ещё что-то поменять, потому что дальше уже, как мы обговорили, результатом работы вижена является здание на архитектурные работы, и там уже ничего поменять практически нельзя. Это уже

168: Пройдя вот эту всю ромашку, вернувшись на придя к эйч стадии.

169: Можно будет сформировать новое задание. Вот.

170: Стейкхолдеры делятся на влияем на влияющих, не влияющих, сильно влияющих, мало влияющих. Если действительно их много, то лучше для себя расписать их по

171: Их степени влияния и уровню заинтересованности. То есть у нас вот так организованы уровни влияния заинтересованности, то есть

172: Чем выше и что с ними делать. То есть вот тут указано, например, чем выше

173: Властный уровень у стейкхолдера, допустим, и чем меньше его его уровень заинтересованности, то его вот, например, можно просто на него можно условно, ну тут не обращать внимания или же просто информировать, да, те, которые

174: Которые и влиятельные, и наиболее заинтересованы. Это у нас ключевые игроки, мы их уделяем, ну, остальные как бы в основном в курсе. То есть, ну, так оно часто и бывает, когда концепт решения докладываешь, то есть 3

175: 4 тех, кто в основном задаёт вопросы и интересуется, а все остальные сидят, слушают. Вот. Но на этой стадии нужно понимать, кто наиболее заинтересован. Кстати, вот эти игроки, вот эти вот наиболее заинтересованные,

176: Они могут быть необязательно своими. Это может быть и госорган, или регулирующий орган, или ещё кто-то. То есть условно как смотреть на это, кто может заблокировать то, что вы сделали, у кого больше власти и желания то

177: Вот эти вот, да, заблокировать могут, понятно, все вот эти, только если захотят. Вот, но у них нет сил, а вот эти не хотят, но у них как бы власть есть, но им не надо, ну, условно, потому что

178: Не совсем они там, они там просто сбоку как-то присутствуют, вот, или отменить это решение, или влиять на него. То есть там, условно говоря, есть, может быть, заинтересованные те, кому нужно сирм систему купить и

179: А вы говорите, будем сами разрабатывать. Вот это у них есть власть и влияние на то, чтобы ваше решение поменять. Вот.

180: Планирование от вызовов и возможностей это немножко такая концептуальная вещь, она появилась

181: В министерстве обороны американской, как такая карта вызовов и наших ответов на на них.

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

183: Перспективы компании.

184: И какие организационные результаты нужно? Какие организационные действия нужно сделать для того, чтобы это достичь? Потому что vision он не только про системы, мы про

185: Просто нам ближе говорить о системах, он на самом деле и про процессы, и про данные.

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

187: Или же данных не будет хватать. Например, вы хотите какую-то систему рыночного риска расчётов сделать, но у вас нет данных по по red по истории клиентов, потому что вы их просто не хра.

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

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

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

191: Данные клиентов нужно хранилище, допустим, а они, может, не готовы, да, то есть возможности нет его приобрести, поэтому, допустим, они будут согласны с тем, что

192: Расчет будет не очень точный, они его потом руками досмотрят. Ну, это такой просто пример абстрактный, да.

193: Вот, ну здесь же также формируется гэп гэп гэпы, то есть пропуски в том, что есть и на этапе гэп анализа, как я уже показывал, они рассматриваются

194: Оценки готовности бизнеса к трансформации. Это немножко такая очень чувствительная тема, потому что, опять же, она затрагивает не, не приложение технологии, она затрагивает бизнес.

195: Slow slow данных и в основном это здесь у нас, казалось бы, финансирование будет основным, скажем так, блокером и стопером. Нет, на самом деле вот, вот это у нас является блокером топе, это

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

197: Что процесс был такой, ну, условно, там имел 3 стадии, а теперь он должен иметь 4, 5, 6 стадию, которые стоят посередине, и какие-то менеджеры должны делегировать свои полномочия. Кому-то это не всегда.

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

199: Здесь в основном об изменении бизнес процессов.

200: Если есть вопросы по этой теме, пишите, можем отдельно обсудить, но

201: Vision должен показывать, как процессы будут меняться и кто должен поменяться.

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

203: То тут должны, они должны быть сделаны по методологии смарт, то есть специфик межр за time. То есть они должны быть конкретными, измеряемыми, достижимыми на результат и

204: Ограничены по времени, то есть измеряемыми. Вот измеряемые. Это очень важно. Вы когда, когда бизнес сценарий разрабатывается, если в нём непонят, н, отсутствует измеряемый критерий успеха, то есть дефинишн оф дан, его нельзя

205: Померить. Ну, условно сделайте, нам хорошо. Вот это хорошо должно быть описано в измеряемых терминах, то есть улучшить время ответа систем там на 30% нормально или время восстановления?

206: Систем должно быть не более чем там 2 часа нормально можно померить, да, но система должна работать плавно. Это не неизмеряемый результат, да, вот поэтому

207: Обязательно надо в измеряемый результат все сводить.

208: Тогда будет успех. Сразу забегая вперёд, вы скажете, что существуют некие качественные критерии успеха. Да, но их нужно перевести в количественные, и для них есть методики. 1 из методик перевода качественных показателей.

209: Показатели успеха, результатов и перевода их в количественные это

210: Например, метод экспертных оценок, там, когда они оценивают от 1 до 10, выставляют оценку, и вы дальше высчитываете из них различные показатели, и это сразу качественное, количественное переводит.

211: Вот вижн также должен показывать, как

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

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

214: Это техника, экономическое обоснование проекта. Условно. Да? Ну, очень похоже на это. Здесь особенно сказать нечего. Важно. О том важно учитывать.

215: Риски, риски, важная часть. Нужно обязательно подсвечивать риски, определять их риски разделяются там на начальные остаточные. Это кто проектами занимается? Хорошо знает, кто занимается управлением.

216: Тоже хорошо знает. Риски бывают регулярные, да, систематические, единичные. Какие-то. Нужно составлять карту рисков. Нужно составлять карту угроз. Если это нужно оценивать, вероятность наступления указывать

217: Как, какой риск будет, какими средствами он, собственно, нейтрализуется? Стоимость этих рисков тоже нейтрализация этих рисков тоже указывать, показывать. Ну, если, если риск частый вероя,

218: Да, но стоимость его высокая, то тут, скорее всего, стоит задуматься, что что-то не то нужно. Нужно, нужно пересмотреть, скорее всего.

219: И результатом, как я уже говорил, является обновлённые версии документов. Почему? Потому что мы все проходим через хранилище, через хранилище архитектурных документов, через хранилище требований.

220: Там у нас они были, они изменились. То есть мы здесь формируем, формируем вот заявку на архитектурные работы, но обновляем, обновляем, то есть бизнес принципы, драйверы, архитектурные принципы, оценку возможностей.

221: Вот архитектурный вижн формируем, формируем также черновик документа. План взаимодействия это план выполнения непосредственно

222: Того, кто как что будет делать, на каком этапе. Вот, вот, то есть все это обновляется, выполняется. Давайте напишем по пройдённому, как что на ваш

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

224: Дальше интереснее, потому что дальше практика. Посмотрим вижн на практике посмотрим настоящий документ. Ну, документы, которые используют

225: Пишите в чат.

226: И вижу на практике.

227: Что такое заявка на архит? Заявление на архитектурные работы это непосредственно, как я уже говорил, шаблон, шаблон системы, шаблон архитектуры системы, да, в нём определяются новые компоненты, определяются

228: Влияние определяются изменения в нём определяются потребности в ресурсах, некие как бы дорожные карты, графики, могут быть приложены функциональные, нефункциональные требования. Определ

229: И то, как решается вопрос функциональных нефункциональных требований, это, собственно, драфт, заявки на архитектурные работы, это то, что мы

230: Давайте посмотрим некоторый вижн. Это он в виде схемы здесь представлен, но они часто и представляются в виде схемы. Это вот он, в нотации спаркс интерпрайза. Архитект представлен, это кусо.

231: Из существующей системы вырезан, да, так, чтобы, ну, максимально, максимально анонимизировать, да, но что важно, что важно на этом вижене, на этом вижене, во первых,

232: У нас отражены вот системы интеграционная система информатика пауэр центр у нас определена, у нас определена, определена какая-то система, которая называется область выгрузки. Она также состоит из 2 подсистем. Вот область выгрузки. Такая

233: В область выгрузки депп менеджер у нас определена ещё 1 система. У нас здесь также показана ещё система, у нас определены вот этими вот кружочками интерфейсы, направление воздействия. То есть у нас здесь указано, что вот этот интерфейс воздействует вот на вот этот

234: Интерфейс, да, и какие данные вот тут написано данные коллекшн, например, да, по нему передаются. Также вот мы видим, что все интерфейсы, что все

235: Что все интерфейсы, вот что все интерфейсы вот подписаны, указаны и везде указано, какой состав данных передаётся, да, какие данные передаются. Вот здесь везде указано. Вот.

236: И вот так вот все системы, значит, почему они выделены цветом. Это очень важно, потому что, ну, как в этой нотации непонятно, но, скорее всего, какие-то из систем являются изменяемые, вот фиолетовенькие, скорее всего, это изменяемые, то есть в резуль

237: Реализации этого вижена и этой архитектуры. Вот эта система изменяется. А зелёные это, допустим, они не меняются, эти системы, да, там на следующих

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

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

240: Это вот такой пример. Здесь вот более схематично, более общее, но

241: Скажем так, более полно указано. То есть вот посмотрим сначала сюда на условное обозначение. Фиолетовые системы, это у нас изменяющиеся системы зелёненькие, они у нас создаются.

242: Жёлтые у нас сохраняются красным, внешний и самое главное у нас указано воздействие, воздействие, это могут быть вызовы или потоки данных, да, на систему, но у нас указано цветом выделено поток.

243: Данных, который создаётся, который меняется и который сохраняется неизменным. И уже взглянув на вот этот vision, на диаграмму, это не весь вижн, это только диаграмма, как бы схема, да.

244: Видно, что существует некая аналитическая система, которая изменяется в ней, создаётся вот зелёным указано 3 пайплайна, которые создают новые потоки данных в

245: Изменяемый слой хранения бронза это из него создаётся поток данных в функцию формирования витрины, слой хранения сильвер, формирование онлайн витрины, слой хранения голд, которым заинтересованы пользователи.

246: То есть вот этого взаимодействия не было. Раньше они начинают им пользоваться. Системы 2, 3 и 4 системы системы. 2, 3 и 4 являются у нас источниками данных для аналитиче.

247: Система, вот у неё указаны вот эти вот потоки данных, да, система 1 у нас в целом сохраняется, но в ней изменяются модули 1, 2, модуль 3 и создаётся новый модуль. Ну вот новый сервис 1, да.

248: Который, что, который меняет, который получает поток данных, но меняет поток данных в целом из системы в аналитическую систему. То есть вот этот поток данных существовал, существовал ранее, а теперь он изменяет

249: Ранее в систему документы подавались по существующему потоку, но теперь он изменяется в рамках. Система 2 существовала, но изменяется и меняет поток данных или взаимодействие. Вот подписано, что

250: Данные 3, там данные 4 основные потоки, прочее. Вот так схематично можно решение показать, выделить цветом и удобно посмотреть c4 модель это 1 из моих, сказать, нелюбимых.

251: Но предпочитаемых подходов, да, ц, 4 модель, она, как известно, состоит из 4 уровней. То есть это концепт контейнера компонента и код, да.

252: Здесь достаточно как бы концепты компонентные для вижена указать. То есть это примеры из интернета, но концептуально здесь тоже указано основные действующие компоненты. То есть это у нас вот это у нас неизменяемые системы.

253: Вот это у нас изменяемые или создаваемые системы, да? Вот, а

254: На компонентах тоже самое, но тут более детально, да, то есть тут у нас уже веб приложение выделено мобильное приложение апи базы данных, там прочее, прочее. Вот для вижена достаточно 2 уровней. То есть, ц, ц, ц, 4, 1, ц, 4, 2.

255: Уровень 3, он более детальный для вижена он рановат, а, ц, 4. Ну, 4 уровень. Архитекторы обычно туда не погружаются, потому что если начинают погружаться, что-то не так с процессом. Вот.

256: Вот такая вот у нас история. Теперь посмотрим некоторые документы, которые у нас на практике по факту выглядят, как вот, например,

257: 1 из документов хочу вам показать, так называемый, это проработка бизнес функции.

258: Какие в нём разделы? Ну, это некий общий раздел, может быть, и не быть, как описывать вот бизнес кейс или бизнес функцию, чтобы дальше её передавать. Важно, что обязательно. То есть, н,

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

260: Функциональности или фактический смысл здесь либо описание процесса, либо диаграмма процессов, либо vpn юмэ юскейс и прочее, прочее здесь обязательно область реализации функциональности, то есть.

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

262: Что является источниками данных, что является получателями данных, какие, по какой, по какой форме эти данные организованы, какие примеры данных можно представить.

263: Что является результатом работы, может быть, новые данные создаются, а интерфейсы указываются, кто является потребителем данных непосредственно, где хранятся ли данные и сколько, как долго.

264: Какая ротация у этих данных существует? Экранные формы здесь эскизы, окружение определяется, от каких функций данная функция зависит или от каких функций данный бизнес кейс зависит, или от каких кейсов он зависит и от каких процессов.

265: Зависимость, на что он влияет? Ну то есть обеспечивает или влияет, на что он влияет, на какие другие функции обязательно доступен ли он из интернета.

266: Или это закрытый? Какие нефункциональные требования предъявляются? Ну то есть объёмы данных, производительность, восстановление?

267: Критичность, да, все нефункциональные обязательно раздел безопасности, да, то есть, ну, из простого, доступен ли он авторизованным пользователям или неавторизованным пользователям? Существует ли у него ролевая модель, если существует, то где испол,

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

269: Ну, дополнительная информация это литература для чтения, это какие-то наброски, эскизы, прочее, прочее. А вот как выглядит.

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

271: Создаётся, да, в нём тоже есть раздел, то есть начинается с общего описания простыми словами.

272: Есть общее описание, да, простыми словами есть функциональная архитектура, здесь обязательно описываются функции основные обеспечивающие, они делятся на фронтальные и внутренние. Все их надо обязательно расписать, потому что они

273: Определяет функциональное наполнение, технологическая карта. Здесь описываются бизнес процессы, бизнес процессы в виде схем, желательно в виде схем. Можно словами, но в виде схем лучше информационная архитектура, бизнес данные как

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

275: Ну, включая микросервисы, которые, согласно архитектурным нотациям, тоже могут быть модулем или компонентом. Ну, условно, это вот как раз уже ц, ц, 3 идёт уровень.

276: Да, иногда, ну, ц, 4 нет, потому что класс не описывается, но это вот в этом документе уже c3 описывается, вот здесь вот модуля компонентов и таблички обязательно идут, которые описывают схему, что указы

277: То есть какой модуль, как он обозначен на схеме, какое функциональное наполнение, для чего он нужен? Че он делает? Вот информационные потоки указываются, откуда, куда, какие данные, через что персональные данные, есть ли или нет. Вот как я уже.

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

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

280: Куда нужен и вам его открывают, да? Или не открывают? Зависит общие сетевые папки. Ну, какие-то общие ресурсы, какие субд применяются, какие средства? Балансировщики, какие ди актив, диктор.

281: Какая аппаратная часть используется? То есть это непосредственно серверы и виртуальные машины, которые будут использоваться. Контейнеризация используется какие-то требования специальные к по может это покупное по, может ещё какое-то какие то требования к лицензии.

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

283: Здесь смотрели это все продакшн, то есть prod это контур prod, где непосредственно реализуется бизнес процесс, но существует также девелоперский контур, тестировочный контур другой нагрузочного тестирования контур, они все должны быть.

284: Тоже со своими схемами, со своими диаграммами, со своим взаимодействием, со своими.

285: Аппаратно программными ресурсами. Ну какие дополнительные и разделы б, то есть какие объекты в системе подлежат защите, как осуществляется аудит баз данных, Логов, хранение файлов, резерв.

286: Копирование, прочее, прочее. Ролевая модель права пользователя описывается. То есть какая ролевая модель используется, используется ли и какие технические учётные записи, если система реализует апи и у вас существует система публикования апи там take.

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

288: У нас здесь.

289: Черновик документа, определение архитектуры. Вот мы его посмотрели, это тот длинный вот, вот так подведём итог из нашей практики.

290: Мы практику, ну, какую-то практику посмотрели, схему посмотрели и документы готовьте вопросы, будем в ходе дискуссии на них отвечать, а пока как архитектурный вижн соответствует принципам agile манифест.

291: Как мы знаем, существует 12 принципов agile manifesto, они здесь, на русском языке, приведены, да и мы посмотрим, соответствует, можно ли, соответствует ли вижн этим принципам или нет.

292: То есть 1, 1, 1 принцип отжал манифест. Это приоритетом для нас является удовлетворение потребностей заказчика.

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

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

295: Продукт.

296: Что это такое?

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

298: Группами работать и таким образом

299: Вас это объединяет. Над проектом должны работать мотивированные профессионалы. Понимаете, профессионалы работают по методикам, а vision это методика, поэтому методика объединяет профессионалы любят методики. Непосредственно. Общение является наиболее практичным, эффективным. Ну да, вина вижн.

300: Через коммуникации.

301: Работающий продукт основной показатель прогресса. Ну мы уже определились, что vision определяет работающий продукт, иначе не очень понятно что это такое.

302: Инвесторы разработчики по должны иметь возможность поддерживать постоянный ритм бесконечно. Джайл помогает наладить такой устойчивый процесс ну, я бы здесь сказал, не только вижу, но весь edm помогает наладить такой устойчивый процесс, как я уже сказал, он всегда есть просто.

303: Не всегда выделено определён. Вот, но также процесс может опираться на требования, определённые в постоянное внимание к техническому совершенству и качеству проектирования.

304: Ну, вижн отражает идеальную архитектуру проекта и шаги, и переходные архитектуры, и шаги для их достижения. Простота искусства. Минимизация лишней работы крайне необходима. Чем системнее мы работаем, тем

305: Меньше усилий мы прилагаем, поэтому вижн часть систематизации, поэтому минимизация, самые лучшие требования архитектурно технические рождаются у самоорганизующихся команд. Бесспорно, каждая команда, ещё раз говорю, проходит все стадии Дима, и

306: Там тоже создаётся, он может быть не документом. Вы можете собраться в комнате и поговорить возле белой доски, порисовать что-то на бумажке. Ещё что-то это и есть vision, просто вы его не оформляете.

307: Команда должна систематически анализировать возможные способы улучшения эффективности и корректировать это, ну, прям задача вижн.

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

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

310: Значит, нужно нам заполнить опросник у занятий. Сейчас я дам ссылку.

311: Нам очень важно, чтобы была обратная связь, она очень ценится и приветствуется. Поэтому, если будем благодарны за то, что вы заполните опрос, а

312: Дальше я немножко расскажу о том, ссылка есть, есть, а дальше я немножко расскажу о том, как проходит процесс обучения в otus и знакомство, знакомство с курсами. Значит процесс обучения у нас. Происходи.

313: В живом формате по вечерам это 2 раза в неделю, примерно где-то в 19 часов по Москве начинается полтора часа, где-то идёт занятие, все записи и материалы, лекции сохраняются. У каждого ученика есть

314: Свой личный кабинет, есть домашний, есть система домашних заданий, которые по которому

315: Так, такой страницы нет, интересно, что ж такое-то? Ну, не знаю, что выдали.

316: Не знаю, что выдали. Давайте ещё раз скопирую как-то.

317: Может быть, не так скопировалось.

318: В любом случае, может быть.

319: Скорее всего, с вами свяжутся по итогам, там можете сообщить. Ну, как-то так. Попробуем. Ссылка, которую мне дали.

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

321: Ну, примерно вот так выглядит интерфейс у отуса по части тогов у нас вот такая программа обучения, то есть знакомство.

322: Понятия, цикл, инструменты, как применяется, какие артефакты, как

323: Да ну хорошо.

324: Как управляется архитектурой и как ведётся проектная работа. То есть если мы говорим про архитектуру корпорации, то у нас

325: Проектный проект есть в конце, его нужно сделать, защитить. Очень интересно. Я был на нескольких защитах, мне понравилось.

326: Преподаватели курса все с большим опытом, с большим опытом архитектурной работы.

327: Так, это мы обсуждаем, обсудим сейчас, и следующий курс начинается в феврале. Записывайтесь, приходите.

328: В принципе, все у нас, я готов отвечать на вопросы, которые есть в чате. Сейчас я попробую привлечь внимание, что у нас есть некие проблемы с

329: Может быть, нам дадут другую ссылку?

330: Интерпрайс архитект, он нацелен только на работу, на роль вопрос чем отличаются курсы интерпрайс архитект и архитектур корпорации итогов 10 тогов 10 курс рассказываю.

331: По методике тогов 10 и частично готовит к сертификации на тогов интерпрайз архитект это рассказ о том, каким образом реализовывать свою роль.

332: Архитектора интерпресс сектора компании, то есть она более специфичная, более профессиональная. Так, пока ждём

333: Вот.

334: Сейчас, секундочку, я тут как раз в онлайне, сейчас решим вопросы технической поддержки.

335: И перейдём к ответу на вопросы. Так правильно ли я понял, что соответствие арх принципам и ограничения технологий проходят на этапе вижена? Да, они проходят на всех стадиях, но на этапе вижена вы можете

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

337: Формально на этом этапе не привлекается, на этом этапе привлекается архитектор.

338: Того уровня, которому поставлена задача. Дело в том, что цикл им это не, он не обязательно на уровне корпорации целиком реализуется, он может реализовываться и на уровне просто системы, может даже

339: Поэтому кто привлекается на этом этапе? Архитектор 100%, кого архитектор выберет для ответов на свои вопросы и дальнейшие это

340: Открыто, открыто к дискуссии кого кого посчитает нужным, условно, того и привлечёт, но на этапе вижена вы можете ещё бизнес требования поменять.

341: Это условно, если к нашим реалиям перейти, это вот на созвоне поставили задачу, знаете, там надо у нас вот данные похранить, и там вот присутствует там, условно, архитектор или у вас архитектора нет у вас?

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

343: Значит, какого объёма? А как часто? А вы знаете, что если нам добавить столбец, это нам надо, у нас сильно связана структура. Это 6 месяцев. Бизнес присутствует такой 6 месяцев. Ну хорошо. А как попроще, а попроще можем?

344: Отдельную базу данных сделать. Давайте туда ну давайте туда сделаем тогда это тогда нам надо как бы 2 запроса делать. Ну хорошо, 2 запроса это там месяц разработки устраивает устраивает вот это vision был

345: Понимаете, но простой пришла архитектурная задача хранить данные определённого объёма и формата. И вы вот так вот вижн сформировали.

346: И изменили бизнес, бизнес требования.

347: Так, следующий вопрос.

348: Я так понимаю, что бизнес трансформейшн Семён как часть фазы, а на сайте то описана в виде методологии бите бизнес, которая предлагает анализировать факторы через модель зрелости, факторы трансформации, модель

349: А можете подсказать методику оценки? Есть ли у вас примеры? Проводится такая оценка у компании в реальности? Участвовали ли вы в такой оценке? Был бы очень признателен, покажет хотя бы 1 фактора, да?

350: Я несколько раз участвовал в фактах оценки зрелости компании и подразделений с точки зрения архитектур.

351: Это такая регулярная деятельность вообще то должна быть и создаются методологии, как оценивается зрелость. Значит, чем больше компания готова к трансформации и

352: Каждый компонент готов к трансформации, меньше завязан на другие компоненты, тем выше у неё степень готовности к трансформации.

353: Чем меньше у компании в части процессов завязок на какой-то центр или на какую-то точку, тем опять же выше готово трансформации.

354: Сейчас приведу пример.

355: Есть, например, в банке центральная система, реализующая это практически во всех банках. Сейчас есть, и от них избавляются, кстати.

356: Банки покупали центральную систему корбанк систем, да, и завязывали на неё очень много процессов. Помимо кор банкинг именно в этой системе реализовывали

357: И там, там существует жёсткая связь на уровне данных и на уровне системы.

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

359: Вторично. Ну, 2 раз.

360: Поэтому здесь готовность к трансформации невысокая кор банковская система, которая условно обеспечивает коровские процессы.

361: И которая взаимодействует с

362: Другими системами через, скажем так, слабую связь, ну, через api взаимодействие или через там mq системы, или вообще отложенным взаимодействием, она более готова к трансформации, потому что тогда каждый

363: Из компонентов можно масштабировать, перенести в другой филиал, разделить, разделить функции филиалов здесь часть функций оставить в 1 филиале часть функций перенести в другой филиал точно также сервисы можно.

364: Бизнес сервисы, например, в 1 филиале будут юридические лица, в другом физические и кор. Банкинг, например, останется только в филиале, где

365: Юридические лица, а где физические лица, там курбан не будет, там будут какие-то обеспечивающие вторичные сервисы. Вот, ну, которые нужны для работы с с посетителями непосредственно за

366: Заявки, например, на риск не будут обрабатываться в филиале, где или, наоборот, обработка заявок на риск будет обес производиться в филиале, где

367: Физические лица, а источник данных будет там, где кор, банкинг стоит. Ну вот такой вот пример готовности к трансформации чем больше, чем больше связанность систем процессов друг с другом и

368: Зависимость тем меньше готова к

369: Тем меньше все готово к трансформации с точки зрения процессов ну, 1 из 1 из критериев это было соблюдение методологии agile, например.

370: У нас.

371: Это выставление задач, это работа с принтами, это цели спринтов, это ревью, это

372: Это оценки задач и и обзор спринта. Вот для для заказчика, потому что от заказчика получается быстрее обратная связь. Соответственно, ты можешь следующий спринт взять и реализовать. Ты больше готов к трансформации.

373: Выполнение системами паттернов надёжности.

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

375: И прочего паттернов тоже определяет готовность трансформации. Это целая методика и большая оценка делается.

376: Вот в вижене тоже надо это учитывать, потому что, как я уже говорил, вижн, он может попросить поменять процесс, поменять процесс или поменять часть системы, а её поменять нельзя. Поэтому, очевидно, придёт.

377: Делать вижн конечный и несколько переходных.

378: Как будем меняться?

379: Вот если арх принцип, если арх принцип мешает трансформации, меняем арх принцип.

380: Очень сомнительно.

381: Скорее нет. Дискуссионный вопрос. Если можете пояснить, то очень интересно. Или пример привести, что значит арх принцип может менять, мешать трансформации. То есть у нас арх принцип.

382: Вы имеете ввиду, что у нас там условно монолит используется? Мы взяли себе такой арт принцип использовать монолит, а нам надо трансформироваться. Давайте трансформируем.

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

384: Но если мы взяли себе принцип быть монолитом.

385: И нам надо трансформироваться. Можем ли мы отменить этот принцип скорее? Да, вопрос интересный. Вопрос интересный. Можно подискутировать? Конечно.

386: Однозначного ответа нет на этот вопрос.

387: Хранить данные. Это не бизнес задача. Это правда. Я просто пример из головы привёл. Видимо, бизнес задача. В этом случае, например, необходимо анализировать продажи за период. Да, это правда, бизнес. Задача должна действительно отображать бизнес результат, хранить данные.

388: Это, ну, такая фигура речи у меня была. Я согласен. Спасибо за замечание.

389: Анализировать продажи за период. Это более правильная постановка будет, да?

390: Коллеги, как думаете, достигли вы цели нашего онлайн вебинара или нет? Пишите.

391: Было ли интересно, оставляйте обратную связь, я тогда поставлю запись на паузу. Спасибо всем за внимание. Можем ещё.