Problems of implementation of end-to-end business processes in distributed architectures (including micro-service). Theses - "The widespread introduction of architecture based on microservices made us take a critical look at the basic tools and dogmas of enterprise Architecture. The situation was aggravated by a significant decrease in the "entry threshold" to the new tool stack, which flooded the industry with developers and designers with incomplete and sometimes eclectic ideas about the theoretical basis for building complex distributed information systems. They prefer to experiment rather than "theorize", believing that since absolute knowledge does not exist, then let the market or the consumer evaluate the ready-made solution "more honestly" than listening to the criticism of technologists and fellow workers. This led to the emergence of projects in the style of "Fast fail", which in the developed theoretical base

6. Потребности
Намерение
Ценности Цели
Результат
Удовлетворение

7. Потребности
Намерение
Ценности Цели
Результат
Удовлетворение

8. • Слом традиционных систем разделения труда
(по профессиям и локациям) в сторону
«виртуального мира»
• Дискриминация лиц и организаций, с низким
уровнем цифровой грамотности и доступа к
цифровым ресурсам (software,hardware,data)
• Поиск групповых зон доверия, в т.ч. отказ от
собственного мнения и конформизм . Поиск
«цифрового доверия»
• Стресс повышает потребность членов группы в
определенности, простых и окончательных
решениях «need for closure»
• Пересмотр моделей риска и стратегии развития
бизнеса
• Возрастает влияние лидеров (и растет «цена
его ошибки»)

11. TechQuilibrium is the balance point
where the enterprise has the right mix
of traditional and digital capabilities
and assets, to power the business
model needed to compete most
effectively, in an industry that is being
digitally revolutionized

12. •
•
•
•



13. •
•
•
•
•
     
t
e
t
e
t
e L
C


 
t
eC
 
t
eL
текущие расходы складываются из текущих
затрат/издержек (Costs) и текущих потерь (Losses)
Costs = намеренные расходы (издержки, затраты), о
наступлении которых точно известно. Например,
комиссии, уплачиваемые компанией, стоимость
расходных материалов, стоимость рабочей силы
Losses = нежелательные и непредвиденные расходы
(потери), которые могут, но не обязательно, произойти.
Например, потери в результате реализовавшихся
операционных рисков, штрафные санкции регулятора

14. Способ
Форма
эффективности
Мероприятия
Максимизировать
поток доходов
Рыночная
эффективность
Продавать больше
Продавать дороже
Минимизировать
поток расходов
Операционная
эффективность
Производить дешевле
Снизить потери
Максимизировать
время жизни
Эффективность
управления рисками
Бороться с рисками
ликвидации компании
   
 
 

Life
T
dt
t
e
t
i
P
0
 
 
t
i
Max
 
 
t
e
Min
 
Life
T
Max

15. • Новые цифровые
возможности, продукты и
услуги в ответ на изменения в
поведении и потребностях
клиентов
• Новые партнерские отношения
как внутри отрасли, так и за ее
пределами
• Корректировка цепочки
поставок и операционной
модели для управления
рисками
• Изменения модели продаж
• Более быстрая разработка
продукта за счет более
быстрой интерации
«За два месяца локдауна COVID19 мы
стали свидетелями цифровой
трансформации как за два года»
Ген.директор Microsoft
Сатья Наделла

16. AS IS
TO BE
ОБСЛЕДОВАНИЕ
РАЗРАБОТКА

18. •
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

20. СВОЙСТВО ЧЕЛОВЕК+СИСТЕМА СИСТЕМА+СИСТЕМА
НАБЛЮДАЕМОСТЬ ДА НЕ ТРЕБУЕТСЯ
ДОКУМЕНТИРУЕМОСТЬ ДА НЕ ТРЕБУЕТСЯ
СЛОЖНОСТЬ НИЗКАЯ (~7 ОБЬЕКТОВ) НЕТ ОГРАНИЧЕНИЙ
РЕАКТИВНОСТЬ НИЗКАЯ ( > 500 ms) НЕТ ОГРАНИЧЕНИЙ
ЯЗЫК (ОНТОЛОГИЯ) ЕСТЕСТВЕННЫЙ НЕТ ОГРАНИЧЕНИЙ
КОГНИТИВНЫЕ ИСКАЖЕНИЯ ДА НЕТ
ЛОГИКА ПРОСТАЯ НЕТ ОГРАНИЧЕНИЙ
ПОСЛЕДОВАТЕЛЬНОСТЬ ЛИНЕЙНАЯ НЕТ ОГРАНИЧЕНИЙ
ОПОРА НА ЦИФРЫ/ДАННЫЕ НИЗКАЯ НЕТ ОГРАНИЧЕНИЙ
РАБОЧИЙ ЦИКЛ НИЗКИЙ (2-4 ЧАСА) НЕТ ОГРАНИЧЕНИЙ
НУЖЕН «ПЕРЕВОДЧИК»
ТРЕБОВАНИЙ
ДА НЕТ ОГРАНИЧЕНИЙ
НУЖЕН «ПЕРЕВОДЧИК»
РЕЗУЛЬТАТА
НЕТ ДА
ВНЕШНИЙ КООРДИНАТОР
«КЛИЕНТСКОГО ОПЫТА» (UX)
НЕ ОБЯЗАТЕЛЕН ОБЯЗАТЕЛЕН

21. 20
«Наведенные» качества
от парадигмы
«СИСТЕМА+ЧЕЛОВЕК»
• Ограниченное число «узлов»
и «связей»
• Есть иерархия и подпроцессы
• Простой топологический граф
• Продвижение только вперед
• В каждый момент только одна
операция
• Четкая «фазность»
• Единый контекст
• Нет жестких требований по
реактивности

22. 21

23. 22

24. 23

25. 24

26. 25

27. 26

28. 27
Latency = 𝑘=1
𝑛
𝐿𝑎𝑡𝑒𝑛𝑐𝑦 (𝑘)
Latency = Max(𝐿𝑎𝑡𝑒𝑛𝑐𝑦 𝑘 )

29. 29

30. 29

31. 29

32. 31

33. 32

34. 33
Шлюз: сервер, который выступает в качестве поставщика интерфейса API, получает
запросы API, применяет политики туннелирования, дросселирования и безопасности,
передает запросы во внутреннюю службу и затем передает ответ обратно
запрашивающему. Шлюз часто включает в себя механизмы преобразования данных и
параметров и изменения запросов и ответов «на лету».
Инструменты публикации: набор инструментов, которые поставщики API используют
для определения API-интерфейсов, например, используя спецификации OpenAPI или
RAML, генерируют документацию API, управляют политиками доступа и использования
API-интерфейсов, тестируют и отлаживают выполнение API, включая развертывание
тестов API-интерфейсов в производственных, промежуточных и контрольных средах,
обеспечения качества и координирование общего жизненного цикла API.
Портал разработчика / магазин API: сайт сообщества, обычно верифицируемый
провайдером API, который может обьединять для пользователей API технические
описания в единую удобную исходную информацию и предоставлять функциональные
компоненты, включая документацию, учебники, примеры кода, комплекты разработки
программного обеспечения, интерактивную консоль API и «песочницу» (sandbox) для
пилотной версии API, возможность подписки на API и управления ключами подписки.
Отчетность и аналитика: функциональность для мониторинга использования и
загрузки API (общие вызовы, завершенные транзакции, количество возвращенных
данных, количество времени вычисления и другие счетчики внутренних ресурсов,
объем переданных данных). Это может включать в себя мониторинг в реальном
масштабе времени API с оповещением
Монетизация: функциональность для поддержки тарификации для доступа к
коммерческим API. Эта функциональность может включать поддержку настройки
правил ценообразования на основе использования, загрузки и функциональности,
автоматической выдачи счетов-фактур и сбора платежей, включая оплату по
различным каналам – банковский перевод, платежи по кредитным картам и пр.
от API Management к API Economics

35. 34
•
•

36. 35
•
•

37. 29

38. 37
•
•

39. 38
•

40. 39

41. 40

42. 41

43. 42

44. 43

45. 44

46. 45

47. 46

48. 47

49. 48

50. 49

51. 50

52. 51

53. 52

54. 53

55. 54

56. 55

57. 56

58. 57

59. 58

60. 59

61. 60

62. 61

63. 62

64. 63

65. 64

66. 65

67. 66

68. 67

69. 68

70. 69

71. 70

72. Вопрос: Разве Архитекторы Предприятия могут в этих условиях
оставаться в своей «Башне из слоновой кости» и совсем не меняться ?

73. • Ex-covid экономика дала старт реальной цифровой трансформации
– от демократизации до дематериализации, и даже демонетизации
• В ИТ «за сытной жизнью» хлынуло большое число людей из других
профессий – рост «хайповости», «релятивизма», приоритет
экспериментального знания над теоретическим
• Сильная регуляторная «турбулентность», в т.ч. с ИТ стандартами,
облачными технологиями и артефактами shared economics
• Аналитики и архитекторы «старой школы» испытывают атаку
«снизу» от продуктовых команд, и «сверху» от бенефициаров, не
имея инструментов и навыков такого арбитража
• Переход от архитектур «система+человек» к «система+система»
стимулирует появление новых научно-инженерных школ,
изучающих новые явления. Академическая наука и университеты
уступают в скорости и качестве корпоративным университетам.
• Феномен «победитель получает все» в глобальной и локальной
конкуренции