Publicidad

Квантовые эффекты в Архитектуре предприятия.pdf

резидент. проекты "Техно Диасофт", "Медлайнсофт", "Диасофт Системы" – Skolkovo Foundation en Skolkovo Foundation
17 de Feb de 2023
Publicidad

Más contenido relacionado

Similar a Квантовые эффекты в Архитектуре предприятия.pdf(20)

Más de Serge Dobridnjuk(18)

Publicidad

Квантовые эффекты в Архитектуре предприятия.pdf

  1. Потребности Намерение Ценности Цели Результат Удовлетворение
  2. Потребности Намерение Ценности Цели Результат Удовлетворение
  3. • Слом традиционных систем разделения труда (по профессиям и локациям) в сторону «виртуального мира» • Дискриминация лиц и организаций, с низким уровнем цифровой грамотности и доступа к цифровым ресурсам (software,hardware,data) • Поиск групповых зон доверия, в т.ч. отказ от собственного мнения и конформизм . Поиск «цифрового доверия» • Стресс повышает потребность членов группы в определенности, простых и окончательных решениях «need for closure» • Пересмотр моделей риска и стратегии развития бизнеса • Возрастает влияние лидеров (и растет «цена его ошибки»)
  4. 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
  5. • • • •  
  6. • • • • •       t e t e t e L C     t eC   t eL текущие расходы складываются из текущих затрат/издержек (Costs) и текущих потерь (Losses) Costs = намеренные расходы (издержки, затраты), о наступлении которых точно известно. Например, комиссии, уплачиваемые компанией, стоимость расходных материалов, стоимость рабочей силы Losses = нежелательные и непредвиденные расходы (потери), которые могут, но не обязательно, произойти. Например, потери в результате реализовавшихся операционных рисков, штрафные санкции регулятора
  7. Способ Форма эффективности Мероприятия Максимизировать поток доходов Рыночная эффективность Продавать больше Продавать дороже Минимизировать поток расходов Операционная эффективность Производить дешевле Снизить потери Максимизировать время жизни Эффективность управления рисками Бороться с рисками ликвидации компании          Life T dt t e t i P 0     t i Max     t e Min   Life T Max
  8. • Новые цифровые возможности, продукты и услуги в ответ на изменения в поведении и потребностях клиентов • Новые партнерские отношения как внутри отрасли, так и за ее пределами • Корректировка цепочки поставок и операционной модели для управления рисками • Изменения модели продаж • Более быстрая разработка продукта за счет более быстрой интерации «За два месяца локдауна COVID19 мы стали свидетелями цифровой трансформации как за два года» Ген.директор Microsoft Сатья Наделла
  9. AS IS TO BE ОБСЛЕДОВАНИЕ РАЗРАБОТКА
  10. • • • • • • • • • • • • • • • • • • • •
  11. СВОЙСТВО ЧЕЛОВЕК+СИСТЕМА СИСТЕМА+СИСТЕМА НАБЛЮДАЕМОСТЬ ДА НЕ ТРЕБУЕТСЯ ДОКУМЕНТИРУЕМОСТЬ ДА НЕ ТРЕБУЕТСЯ СЛОЖНОСТЬ НИЗКАЯ (~7 ОБЬЕКТОВ) НЕТ ОГРАНИЧЕНИЙ РЕАКТИВНОСТЬ НИЗКАЯ ( > 500 ms) НЕТ ОГРАНИЧЕНИЙ ЯЗЫК (ОНТОЛОГИЯ) ЕСТЕСТВЕННЫЙ НЕТ ОГРАНИЧЕНИЙ КОГНИТИВНЫЕ ИСКАЖЕНИЯ ДА НЕТ ЛОГИКА ПРОСТАЯ НЕТ ОГРАНИЧЕНИЙ ПОСЛЕДОВАТЕЛЬНОСТЬ ЛИНЕЙНАЯ НЕТ ОГРАНИЧЕНИЙ ОПОРА НА ЦИФРЫ/ДАННЫЕ НИЗКАЯ НЕТ ОГРАНИЧЕНИЙ РАБОЧИЙ ЦИКЛ НИЗКИЙ (2-4 ЧАСА) НЕТ ОГРАНИЧЕНИЙ НУЖЕН «ПЕРЕВОДЧИК» ТРЕБОВАНИЙ ДА НЕТ ОГРАНИЧЕНИЙ НУЖЕН «ПЕРЕВОДЧИК» РЕЗУЛЬТАТА НЕТ ДА ВНЕШНИЙ КООРДИНАТОР «КЛИЕНТСКОГО ОПЫТА» (UX) НЕ ОБЯЗАТЕЛЕН ОБЯЗАТЕЛЕН
  12. 20 «Наведенные» качества от парадигмы «СИСТЕМА+ЧЕЛОВЕК» • Ограниченное число «узлов» и «связей» • Есть иерархия и подпроцессы • Простой топологический граф • Продвижение только вперед • В каждый момент только одна операция • Четкая «фазность» • Единый контекст • Нет жестких требований по реактивности
  13. 21
  14. 22
  15. 23
  16. 24
  17. 25
  18. 26
  19. 27 Latency = 𝑘=1 𝑛 𝐿𝑎𝑡𝑒𝑛𝑐𝑦 (𝑘) Latency = Max(𝐿𝑎𝑡𝑒𝑛𝑐𝑦 𝑘 )
  20. 29
  21. 29
  22. 29
  23. 31
  24. 32
  25. 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
  26. 34 • •
  27. 35 • •
  28. 29
  29. 37 • •
  30. 38 •
  31. 39
  32. 40
  33. 41
  34. 42
  35. 43
  36. 44
  37. 45
  38. 46
  39. 47
  40. 48
  41. 49
  42. 50
  43. 51
  44. 52
  45. 53
  46. 54
  47. 55
  48. 56
  49. 57
  50. 58
  51. 59
  52. 60
  53. 61
  54. 62
  55. 63
  56. 64
  57. 65
  58. 66
  59. 67
  60. 68
  61. 69
  62. 70
  63. Вопрос: Разве Архитекторы Предприятия могут в этих условиях оставаться в своей «Башне из слоновой кости» и совсем не меняться ?
  64. • Ex-covid экономика дала старт реальной цифровой трансформации – от демократизации до дематериализации, и даже демонетизации • В ИТ «за сытной жизнью» хлынуло большое число людей из других профессий – рост «хайповости», «релятивизма», приоритет экспериментального знания над теоретическим • Сильная регуляторная «турбулентность», в т.ч. с ИТ стандартами, облачными технологиями и артефактами shared economics • Аналитики и архитекторы «старой школы» испытывают атаку «снизу» от продуктовых команд, и «сверху» от бенефициаров, не имея инструментов и навыков такого арбитража • Переход от архитектур «система+человек» к «система+система» стимулирует появление новых научно-инженерных школ, изучающих новые явления. Академическая наука и университеты уступают в скорости и качестве корпоративным университетам. • Феномен «победитель получает все» в глобальной и локальной конкуренции
Publicidad