Тема 4.0 — Техническая архитектура, облако и унаследованные системы

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

Почему это важно в здравоохранении и уходе#

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

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

Они также — решения равенства и доверия. Унаследованные системы, не способные делиться данными, оставляют самых сложных пациентов, затрагивающих много услуг, с наиболее фрагментированными записями. Закрытые платформы, запирающие вас у одного поставщика, истощают деньги, которые могли бы финансировать уход. А общественность разумно ожидает, что NHS работает на современных, защищённых, хорошо поддерживаемых технологиях; разрыв между этим ожиданием и реальным парком сам по себе риск для доверия.

Наконец, это место, где огромные государственные деньги выделяются на очень долгий срок. Самая дорогая часть системы — редко её покупка; это десятилетие хостинга, лицензирования, поддержки и в конце концов замены, которое за ней следует. Руководители, считающие архитектуру «тем, чем занимается техническая команда», делегируют одни из самых крупных и долгоживущих финансовых обязательств, которые принимает организация. Эта тема написана, чтобы вы могли спрашивать за эти решения, не будучи инженером.

Ключевые понятия#

Корпоративная архитектура — дисциплина согласования бизнес-процессов, информации, приложений и технологий организации, чтобы они связно поддерживали стратегию, а не росли случайно. Она берёт взгляд всей организации: какие возможности вам нужны, какие системы их обеспечивают и где пробелы и дублирование. Архитектура решения — более узкая, проектная дисциплина проектирования того, как будет построена конкретная услуга и впишется в более широкий парк. Обе находятся внутри более широкой идеи системной архитектуры: структурной модели того, как компоненты, интерфейсы и поведения объединяются в работающее целое. Руководителям не нужно практиковать эти дисциплины, но следует настаивать, чтобы они существовали, потому что их отсутствие — способ, которым парки становятся неуправляемыми.

Архитектуру направляют архитектурные принципы: короткий, согласованный набор утверждений (например, «повторное использование прежде покупки, покупка прежде разработки» или «строить на открытых стандартах»), делающий возможными последовательные решения без эскалации каждого выбора. Принципы мягко обеспечивает проектный совет (design authority): небольшая группа, рассматривающая значимые технические решения. Здоровая версия проектного совета помогает, а не блокирует; он существует, чтобы предотвращать устранимый вред и дублирование, а не замедлять команды или привратничать ради себя.

Облачные вычисления — предоставление вычислений (серверов, хранилищ, баз данных, сетей) как услуги по запросу через интернет, а не с оборудования, которым вы владеете в собственном здании. Публичным облаком управляет сторонний провайдер, и оно разделяется многими клиентами; частное облако выделено одной организации; гибридное облако сочетает два, часто оставляя часть нагрузок на существующей инфраструктуре и перенося другие. Многие правительства, включая британское, приняли политику «cloud-first», означающую, что команды должны рассматривать публичное облако прежде других вариантов и обосновывать отказ от его использования. Поскольку облако оплачивается по потреблению, а не покупается один раз, контроль этих расходов стал отдельной дисциплиной: FinOps, практикой объединения инженерии и финансов, чтобы команды видели и отвечали за то, во что на самом деле обходится их использование облака. На уровне приложений программное обеспечение как услуга (SaaS) поставляет готовое приложение через веб, которое размещает и поддерживает поставщик, так что вы настраиваете, а не ведёте его. Инфраструктура и хостинг (где и как физически работают ваши системы) лежат под всем этим и всё чаще несут углеродную цену, которая должна входить в решение (см. тему 8.5 — Устойчивость и нулевой баланс выбросов).

Унаследованная система — стареющая, но по-прежнему используемая система, которую трудно изменить, часто работающая на неподдерживаемом ПО, для которого больше не выпускаются обновления безопасности. Унаследованные системы накапливаются как технический долг: будущая цена целесообразных выборов, сделанных в прошлом. Немного долга нормально и даже разумно; неуправляемый долг в масштабе становится обязательством безопасности, потому что системы, от которых зависит больше всего людей, становятся системами, которых никто не смеет коснуться. Управление этим — задача управления портфелем приложений: ведения ясного перечня каждого приложения, его стоимости, состояния и бизнес-ценности, чтобы вы могли рационализировать парк (выводить, заменять или консолидировать системы) и безопасно выводить из эксплуатации, а не оставлять старое тихо работающим.

Современные парки скрепляются интерфейсами прикладного программирования (API): определёнными интерфейсами, через которые одна система предлагает возможность другой. Хорошо спроектированные API позволяют собирать платформы (повторно используемые услуги, на которых строят многие команды), сохраняя компоненты слабо связанными и заменяемыми. Полезная дисциплина здесь — «тончайшая жизнеспособная платформа»: стройте только общую возможность, действительно снижающую чужую работу, и не более. В основе безопасного проектирования лежит принцип безопасности по замыслу (secure by design): безопасность закладывается с самого начала, а не навешивается потом. А финансовая рамка для всего этого — совокупная стоимость владения (TCO): полная стоимость жизненного цикла системы, а не цена покупки; линза, через которую следует судить о выборе «строить/покупать/настраивать» и о риске привязки к поставщику.

Лучшие практики#

1. Согласуйте короткий набор архитектурных принципов и используйте их для решений. Запишите горстку ясных, запоминающихся принципов (повторное использование прежде покупки прежде разработки, строить на открытых стандартах, облако там, где оно оправдано, безопасность по замыслу, проектировать для всего пути ухода) и позвольте командам принимать большинство решений самим, применяя их. Принципы работают, только если ими действительно пользуются, чтобы говорить «да» и «нет», и только если их достаточно мало, чтобы запомнить. Это напрямую связано с темой 1.1 — Операционная модель и темой 1.2 — Цифровая стратегия и дорожное картирование, задающими направление, которому служат принципы.

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

3. Принимайте облако осознанно, нагрузка за нагрузкой, а не как лозунг. Относитесь к «cloud-first» как к значению по умолчанию, над которым нужно рассуждать, а не к указанию переносить всё. Оценивайте каждую нагрузку на пригодность, местонахождение данных, устойчивость, стоимость в масштабе и усилия миграции и будьте честны, что перенос «как есть» неизменённого унаследованного приложения часто просто перемещает проблему с большей стоимостью. Взвешивайте углеродное измерение явно, поскольку то, где и как вы размещаете, влияет на выбросы (см. тему 8.5 — Устойчивость и нулевой баланс выбросов), и проектируйте для переносимости, чтобы будущий переход между провайдерами оставался возможным.

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

5. Рационализируйте парк и безопасно выводите из эксплуатации. Активно выводите дублирующиеся, устаревшие системы и системы конца срока службы, а не позволяйте им задерживаться «на всякий случай», потому что каждая действующая система — поверхность атаки, лицензионная стоимость и бремя поддержки. Вывод из эксплуатации — проект сам по себе: мигрируйте или архивируйте данные по ясным правилам хранения, подтвердите, что от системы ничто уже не зависит, коммуницируйте с пользователями и проверьте до отключения. При хорошем исполнении рационализация освобождает деньги и снижает риск; при небрежном она уничтожает записи или ломает зависимость, которую никто не документировал.

6. Предпочитайте открытые стандарты, API и слабо связанные компоненты. Проектируйте так, чтобы возможности выставлялись через документированные, версионируемые API, чтобы один компонент можно было заменить, не пересобирая всё вокруг него. Это архитектурный фундамент интероперабельности, обсуждаемой в теме 4.3 — Интероперабельность и стандарты данных, и ваша главная защита от привязки. Это стоит чуть дороже заранее, чем прямое, жёстко прописанное соединение, и окупается во много раз, когда впервые понадобится сменить поставщика или добавить услугу.

7. Стройте тончайшую жизнеспособную платформу и не более. Когда вы создаёте общую платформу для других, сопротивляйтесь желанию сделать её всеобъемлющей с первого дня. Предоставьте наименьшую повторно используемую возможность, действительно снимающую работу с команд, докажите, что ею пользуются, и растите её в ответ на реальный спрос. Перестроенные платформы становятся собственным унаследованным грузом (дорогим, жёстким и раздражающим), тогда как тонкая, хорошо ведомая платформа зарабатывает принятие и эволюционирует по потребности.

8. Сделайте архитектуру безопасности и безопасность по замыслу не подлежащими обсуждению. Привносите мышление о безопасности в проект с первого наброска, а не как предзапусковые ворота: минимизируйте поверхность атаки, применяйте наименьшие привилегии, сегментируйте сети и исходите из того, что компоненты будут зондировать. В здравоохранении и уходе это неотделимо от клинической безопасности и управления информацией (тема 1.6 — Клиническая безопасность и управление рисками; тема 1.7 — Управление информацией, защита данных и кибербезопасность), потому что нарушение — и вред данным, и, когда оно останавливает системы, событие безопасности пациентов. Неподдерживаемое, необновляемое ПО — решение о безопасности, которое вы принимаете по умолчанию, так что принимайте его сознательно, со смягчениями, или не принимайте вовсе.

9. Решайте «строить, покупать или настраивать» по совокупной стоимости владения, а не по цене на ценнике. Для каждой возможности сравнивайте разработку на заказ, покупку продукта и настройку существующей платформы по полной стоимости жизненного цикла (хостинг, лицензирование, интеграция, поддержка, обновления и в конечном счёте выход), а не по начальной цене. Предпочитайте покупку или настройку для рядовых потребностей и приберегите разработку для подлинной дифференциации и взвешивайте привязку, которую создаёт каждый вариант. Прорабатывайте это с коммерческими коллегами (тема 6.3 — Закупки и коммерческие вопросы), потому что самое дешёвое время обеспечить открытые интерфейсы и права выхода — до подписания.

10. Рассматривайте расходы на облако как общую дисциплину инженерии и финансов (FinOps). Дайте командам ясную видимость того, чего стоят их услуги, помечая облачные ресурсы владельцами, подгоняя размеры экземпляров под реальное использование и отключая простаивающие или избыточно выделенные ресурсы, а не платя за них месяц за месяцем. Сделайте команды, ведущие услугу, ответственными за её эксплуатационную стоимость, чтобы люди, лучше всех способные сократить расточительство, были теми, кто видит счёт. Облако с оплатой по мере использования без этой дисциплины тихо потребляет бюджет, который должен финансировать уход, а дрейф редко замечают, пока счёт не заставит задать вопрос.

11. Архитектурно закладывайте стоимость как первоклассное нефункциональное требование, взвешивая её против углерода и устойчивости. Относитесь к стоимости так же, как к производительности, безопасности и доступности: свойству, под которое вы проектируете сознательно, оцениваете до разработки и пересматриваете по мере роста использования. Взвешивайте её явно против углерода (см. тему 8.5 — Устойчивость и нулевой баланс выбросов) и против устойчивости, потому что три часто движутся вместе, но никогда не гонитесь за самым низким счётом ценой безопасности, восстанавливаемости или результатов для пациентов. Правильный ответ — самая низкая стоимость, всё ещё удовлетворяющая вашим обязательствам по клинической безопасности и устойчивости, а не самый дешёвый вариант в отрыве.

Вопросы для обсуждения с командой#

1. Какие из наших критичных систем сегодня неподдерживаемы или необновляемы и какова наша реальная уязвимость, если одну из них атакуют или она откажет? Начните с систем, без которых клинические и операционные услуги действительно не могут функционировать, и конкретно выясните, какие из них работают на ПО, более не получающем обновления безопасности или поддержки поставщика. Спросите, что произошло бы (с пациентами, персоналом, данными), если бы каждую поразил вымогатель или она просто остановилась, и сколько заняло бы восстановление. Отличите системы, на которых вы сознательно приняли риск, со смягчениями на месте, от тех, чью хрупкость никто не оценивал. Подумайте, видна ли эта уязвимость в реестре корпоративных рисков или похоронена в таблице, которую никакой совет не видел. Вспомните WannaCry: вред пришёл не от изощрённости, а от известного, не устранённого долга в критичных системах. Если вы не можете ответить на это с доказательствами, этот пробел сам — ваш самый срочный вывод, потому что нельзя финансировать риск, которого вы не назвали.

2. Где мы привязаны и чего на самом деле стоило бы нам покинуть нашу крупнейшую платформу? Многие организации обнаруживают реальную цену закрытой системы лишь когда пытаются её сменить. Проработайте, чего на самом деле потребовал бы переход с вашей крупнейшей клинической или корпоративной платформы: можете ли вы извлечь ваши данные в пригодной, стандартной форме, какие проприетарные интерфейсы пришлось бы распутывать и что говорит ваш контракт о владении и выходе. Подумайте, не стало ли «облако» тихо привязкой иного вида, с данными и инструментами, настолько запутанными в одном провайдере, что уход непрактичен. Взвесьте это против открытости альтернатив и любых национальных платформ, которые вы могли бы использовать повторно. Это не довод за смену поставщиков; речь о понимании вашего рычага до следующих переговоров и о том, чтобы не позволить дорожной карте одного поставщика тихо стать вашим единственным вариантом.

3. Достаточно ли мы инвестируем в поддержание и рационализацию того, что уже имеем, или только в новое и видимое? Новые системы привлекают финансирование и внимание; непривлекательная работа по обновлению, апгрейду, консолидации и безопасному выводу редко, и именно так накапливается долг. Спросите, какая доля вашего цифрового бюджета на самом деле идёт на поддержание существующего парка безопасным и актуальным, а какая на создание нового, и владеет ли кто-нибудь этим балансом сознательно. Обсудите, обеспечивается ли когда-либо должным образом вывод из эксплуатации или старые системы просто задерживаются, потому что их отключение — ничья задача. Подумайте о дублирующихся приложениях, делающих одно и то же по всей организации, и о том, чего потребовало бы их консолидировать. Подумайте, кто на уровне совета отвечает за здоровье парка в целом, а не за отдельные проекты. Организация, финансирующая только новое, берёт в долг у собственной будущей безопасности, а возврат всегда наступает в худший момент.

4. Знаем ли мы на самом деле, чего стоит наше облако, кто владеет этим счётом и под контролем ли расходы? Облако с оплатой по мере использования может тихо потреблять бюджет, который должен финансировать уход, а дрейф редко замечают, пока счёт не заставит задать вопрос. Спросите, помечены ли облачные ресурсы командами и услугами, которым они принадлежат, подгоняет ли кто-нибудь размеры экземпляров под реальное использование и отключаются ли когда-либо простаивающие или избыточно выделенные ресурсы. Обсудите, видят ли люди, ведущие услугу, её эксплуатационную стоимость и отвечают ли за неё, или расходы на облако приходят единой необъяснённой строкой в центральном бюджете, которую никто не может разложить. Подумайте, рассматривается ли стоимость как первоклассное нефункциональное требование (оцениваемое до разработки и пересматриваемое по мере роста использования) или обнаруживается лишь постфактум. Будьте честны в отношении напряжения между инженерной автономией и финансовым контролем и в отношении взвешивания стоимости против углерода и устойчивости, а не просто погони за самым низким счётом. Честный ответ называет, кто держит дисциплину FinOps, и показывает доказательства, что она работает, а не предполагает, что облако дешевле, потому что оно современно.

5. Когда нам нужна новая возможность, как мы решаем между разработкой, покупкой и настройкой чего-то, что у нас уже есть, и на каком основании? Инстинкт строить на заказ или покупать продукт с лучшей демонстрацией часто побеждает до того, как кто-нибудь сравнил полную стоимость жизненного цикла. Проработайте, как на самом деле принимались ваши последние несколько значимых выборов: взвешивались ли хостинг, лицензирование, интеграция, поддержка, обновления и в конечном счёте выход или только начальная цена. Спросите, приберегаете ли вы разработку для подлинной дифференциации и по умолчанию покупаете или настраиваете для рядовых потребностей или разработки на заказ тихо размножаются, потому что команде они нравились. Подумайте, кто в комнате при этих решениях (коммерческие и клинические коллеги, а также инженеры) и оценивается ли привязка, создаваемая каждым вариантом, до подписания, а не обнаруживается позже. Подумайте, действительно ли ваши архитектурные принципы («повторное использование прежде покупки, покупка прежде разработки») связывают эти выборы или тихо игнорируются. Честный ответ может указать реальные решения, где результат изменила совокупная стоимость владения, а не цена на ценнике.

6. Есть ли у нас внутренняя архитектурная способность держать наши собственные решения или мы зависим от поставщиков, которых должны привлекать к ответственности? Архитектура — место, где принимаются самые крупные и долгоживущие обязательства, но многие организации выхолостили именно ту способность, которая нужна, чтобы принимать их хорошо, полагаясь на поставщиков, чьи продукты оцениваются, чтобы те сказали им, как выглядит хорошее. Спросите, есть ли у вас достоверная корпоративная и решенческая архитектурная экспертиза на вашей стороне и укомплектован ли ваш проектный совет, чтобы помогать командам, или лишь штамповать. Обсудите, действительно ли значимые, трудно обратимые решения проверяются относительно согласованных принципов или фактически делегируются тому поставщику, кто ближе к проблеме. Подумайте, как вы вообще распознали бы плохую архитектурную рекомендацию, не имея независимой экспертизы, чтобы её оспорить. Взвесьте цену построения и удержания этой способности против гораздо большей цены привязки и переделок, которые порождает её отсутствие. Честный ответ различает решения, которыми вы действительно можете владеть, и те, что вы сейчас принимаете на веру.

На практике: пример из здравоохранения и ухода#

Технический парк больницы неотложной помощи органически рос два десятилетия. В его сердце — система ведения пациентов на операционной системе, поддержку которой поставщик прекратил восемнадцать месяцев назад; вокруг неё более двухсот приложений, многие купленные ведомственно, несколько делающих пересекающиеся задачи, и ни у кого нет полного списка. Почти-происшествие (попытка вымогателя, заблокированная скорее удачей, чем проектом) побуждает совет задать вопрос, которого он никогда прежде не задавал: что именно мы ведём и насколько мы уязвимы?

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

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

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

Отраслевые перспективы#

Стартап#

У стартапа цифрового здравоохранения есть роскошь малого унаследованного груза, и его следует яростно беречь. Стройте облачно-нативно с самого начала, выставляйте открытые API и относитесь к безопасности по замыслу как к основной функции, а не позднейшей стоимости, потому что осторожные покупатели из NHS будут пристально изучать вашу архитектуру безопасности и условия извлечения данных. Держите вашу собственную тончайшую жизнеспособную платформу действительно тонкой, сопротивляясь соблазну чрезмерно разрабатывать под масштаб, которого у вас пока нет. Ваш самый быстрый путь накопить парализующий технический долг — выпускать целесообразный код под давлением инвесторов и никогда не гасить его, поэтому делайте осознанные, видимые выборы о том, какой долг берёте. Парадоксально, проектирование так, чтобы клиент мог извлечь свои данные и уйти, — то, что зарабатывает доверие, удерживающее его.

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых, клиника в одном месте или небольшой поставщик health-tech, миновавший стадию стартапа) несёт те же обязанности, что и крупный траст, но с долей ресурсов и редко с какой-либо выделенной ИТ-возможностью. Здесь архитектура — в основном дисциплина хорошо покупать: предпочитайте проверенное программное обеспечение как услугу, чтобы поставщик нёс хостинг, обновление и безопасность, которые вы не можете обеспечить персоналом, и читайте контракт на права извлечения данных и выхода до подписания, потому что привязка кусается сильнее всего, когда у вас нет рычагов. Ведите простой перечень немногих систем, от которых вы зависите, и знайте, какие всё ещё поддерживаются, потому что даже небольшой парк может скрывать необновлённую машину, останавливающую практику. Настаивайте, чтобы поставщики соответствовали признанным стандартам, таким как Data Security and Protection Toolkit, а не пытайтесь оценивать безопасность с нуля. Когда деньги туги, соблазн — держать старую, неподдерживаемую систему работающей, чтобы избежать счёта, но это решение о безопасности, которое вы должны принимать сознательно, а не по дрейфу.

Крупная организация#

Крупный траст или поставщик несёт десятилетия накопленных систем и не может просто начать заново. Реалистичная стратегия — дисциплинированная эволюция: поддерживать живой портфель, ставить открытые слои на основе API перед тем, что должно остаться, и погашать самый опасный долг по финансируемому, приоритизированному плану, а не в эпизодических паниках. Ведите проектный совет, которого уважают, потому что он помогает поставке, а не боятся, потому что он её блокирует, и сделайте технический долг постоянным риском уровня совета с названным владельцем. Охраняйте от привязки при каждом продлении и относитесь к выводу из эксплуатации как к реальной, обеспеченной ресурсами работе, а не запоздалой мысли. Это та же дисциплина повторного использования и открытых интерфейсов, что управляет основными операционными платформами в теме 5.4 — Планирование ресурсов предприятия (ERP).

Государство#

Национальные и региональные органы задают условия, в которых работает весь сектор, и их архитектурные выборы расходятся волнами. Самое ценное, что может сделать государство, — предписывать открытые стандарты, предоставлять повторно используемые национальные платформы, чтобы местные организации строили один раз, и задавать ожидания по облаку, безопасности и устойчивости, поднимающие нижнюю планку везде. Решающе важно, что государство должно финансировать непривлекательную национальную работу (устранение унаследованных систем, поддержание терминологии, поддержка вывода из эксплуатации), которую ни одна отдельная организация не профинансирует в одиночку, но от которой зависят все. Твёрдо обеспечиваемый, достаточно хороший стандарт, широко используемый повторно, побеждает теоретически превосходный, реализованный непоследовательно. Эта роль управления связана с темой 9.1 — Работа с местными и национальными правительствами и с тем, как сотрудничают партнёры в теме 9.0 — Сотрудничество с партнёрскими организациями.

Типичные способы сбоя#

• Невидимый парк. Ведение сотен приложений без точного перечня, так что уязвимость неизвестна, дублирование незаметно, а первый признак хрупкости — сбой или нарушение.
• Долг, скрытый от совета. Хранение неподдерживаемого ПО и технического долга как технической сноски, а не названного корпоративного риска, так что он никогда не финансируется, пока не откажет.
• Облако как лозунг. Перенос неизменённых унаследованных систем в публичное облако из принципа, перемещающий проблему с большей стоимостью, или запутывание данных и инструментов настолько глубоко в одном провайдере, что это становится новой привязкой.
• Проектный совет как узкое место. Позволение архитектурному управлению стать медленными воротами, которые команды обходят, порождая недокументированную теневую архитектуру, хуже, чем никакой.
• Строить, когда следовало настроить. Выбор разработки на заказ для рядовых потребностей по цене на ценнике, а не по совокупной стоимости владения, и наследование десятилетия поддержки, которую вы не закладывали в бюджет.
• Никогда не выводить из эксплуатации. Оставление устаревших систем работающими «на всякий случай», каждая из которых — поверхность атаки, лицензионная стоимость и утечка поддержки, которой никто не владеет.
• Безопасность, навешенная сверху. Отношение к безопасности как к предзапусковым воротам, а не входу проектирования, так что поверхность атаки задаётся задолго до того, как кто-либо её оценивает.
• Привязка по умолчанию. Подписание платформ без открытых интерфейсов или прав извлечения данных и обнаружение цены ловушки лишь когда вы пытаетесь уйти.

Модель зрелости#

Контрольный список#

• Живой портфель приложений фиксирует владельца, стоимость, поддерживаемость и риск каждой системы и регулярно пересматривается.
• Неподдерживаемые и необновляемые критичные системы выявлены и находятся в реестре корпоративных рисков, а не в технической таблице.
• Короткий, согласованный набор архитектурных принципов действительно используется для принятия и обоснования решений.
• Проектный совет рассматривает значимые, трудно обратимые решения и быстро пропускает рутинные, помогая, а не блокируя.
• Принятие облака оценивается нагрузка за нагрузкой, с взвешиванием местонахождения данных, устойчивости, стоимости, переносимости и углерода.
• У технического долга есть названный владелец и финансируемый план устранения, а не только эпизодическое тушение пожаров.
• Дублирующиеся и устаревшие системы рационализируются, а вывод из эксплуатации обеспечен ресурсами, с миграцией данных, хранением и проверкой зависимостей.
• Новые возможности выставляют открытые, версионируемые API, чтобы компоненты можно было заменить, не пересобирая всё вокруг них.
• Безопасность заложена с самого начала: минимальная поверхность атаки, наименьшие привилегии, сегментация, а не навешена перед запуском.
• Решения «строить/покупать/настраивать» принимаются по совокупной стоимости владения и привязке, а права выхода и извлечения данных обеспечены до подписания.

Ключевые источники#

• NHS England — облачная стратегия, технологические стандарты и Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — принципы безопасного проектирования и руководство по облачной безопасности.
• Правительство Великобритании (GDS/CDDO) — Technology Code of Practice и политика cloud-first.
• National Audit Office — доклады об унаследованных системах NHS, атаке WannaCry и программах на основе ИТ.
• The Open Group — TOGAF, рамка корпоративной архитектуры.
• Government Digital Service — концепция «тончайшей жизнеспособной платформы» в GOV.UK service manual и сообществе дизайна.

Ссылки#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual