О заполнении шаблона описания архитектуры решения – Архитектура ИТ-решений

Описание архитектуры ИТ-решения не самая простая практика. И уж точно не следует приступать к её освоению с заполнения шаблона описания архитектуры. Тем не менее, такого рода шаблоны существуют и кто-либо из представителей заказчика информационной системы не редко требует описать архитектуру. Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором, и потому я возьму на себя смелость дать несколько рекомендаций о том, как это следует делать. Обычно, в качестве шаблона используются производные от RUP-овского Software Architecture Document скачать который можно, например, здесь. Существенно реже можно встретить TOGAF-овский Architecture Definition Document и уж вряд ли вам попадется ISO-шный Architecture description. Поэтому ориентироваться будем на первый шаблон. Разделы такого документа кроме введений и определений включают следующий набор архитектурных представлений:

• Use-case view
• Logical view
• Process view
• Deployment view
• Implementation view
• Data view (optional)

В общем,  все в строгом соответствии с моделью архитектуры «4+1 architectural view model» от Philippe Kruchten (Иногда к перечисленным разделам добавляют описания программных интерфейсов. Я же люблю дополнять этот документ разделом «Открытые вопросы и предположения».) Казалось бы, все просто. Берем книжку по UML и начинаем рисовать картинки. Сначала UML диаграмму вариантов использования, потом диаграмму классов и т.д… А вот и ни разу не так!

Замечание 1. Разработка архитектуры решения – это процесс, состоящий, как минимум, из следующих этапов:

1. Анализ и структурирование в виде моделей требований и прочей проектной информации. Кстати, для значительного количества моделей, полученных в ходе структурирования проектных данных, раздела в шаблоне не найдется. Это не значит, что их не надо включать в описание архитектуры.
2. Выбор варианта реализации.
3. Описание варианта реализации.
4. Согласование предложенной архитектуры.

Это надо учитывать при планировании и оценке трудоемкости. Кроме того, каждый этап требует различных действий. На первом этапе мы не собираем требования. Сбор требований – задача аналитика и в том или ином виде они должны быть. Мы внимательно их читаем, уточняем, задаем вопросы и структурируем их в виде моделей. Это может быть итеративный процесс внесения структуры в поток требований, но такой поток должен быть. Нет требований – нет архитектуры. Далее. Выбирать и согласовывать вариант реализации лучше до того, как мы плотно займемся его описанием. Меньше придется переписывать. Непосредственно проектирование, т.е. придумывание из головы чего-то нового, занимает незначительную часть времени. Как правило, за нас все уже придумали и потому:

Замечание 2. Традиционный процесс проектирования не подходит для большинства проектов. Обычно в проектах используются уже готовые системы, так называемые COTS (Commercial off the shelf ) или уже существующие ИТ-решения. И потому все перечисленные модели надо основывать на описании уже существующих приложений. Правда, частенько, таких документов не существует и вот их приходится собирать(создавать заново). Тем не менее, вы не можете придумать заново ни свою модель данных, ни компонентную структуру системы, ни варианты использования. Все что вы можете сделать, так это «вписать» требования в существующие решения. Иначе, в худшем случае ваша архитектура нанесет непоправимый вред существующей системе, нарушив её концептуальную целостность, а в лучшем – вашу архитектуру просто выкинут и сделают по-своему. С данными ситуация не самая сложная. Все сущности, которые вы хотите реализовать в системе, должны являть частными случаями уже существующих сущностей. В каком-то смысле это напоминает отношение наследования в диаграмме классов. Но не всегда архитектура используемой системы позволяет реализовать отношения наследования. Чаще работа заключается в том, что вы берете существующую модель данных и придумываете набор типов (стереотипов) для того, что вам нужно на этой модели создать: создаете список типов обращений, придумываете поля заявок и workflow их обработки и т.п. С компонентами – хуже. В принципе, готовая программная платформа должна поставлять вам узлы(nodes, говоря языком UML) для создания и развертывания ваших новых компонент. SQL server(узел) служит для того, чтоб вы создавали собственные компоненты со стереотипами таблица, отношение, хранимая процедура и т.д., BPMS – для моделей процессов, джава-портал – для создания портлетов и т.п. Но когда речь заходит не о программных платформах, а о бизнес-приложениях все становиться загадочным и туманным. Готовое решение, вроде бы есть, но достоверных данных о том, как его следует использовать, что и где на ней нужно создавать и развертывать нет. Это не правильно. Я бы воздержался от использования таких систем.

Замечание 3. На каком уровне детализации остановиться? Безусловно, ответ на этот вопрос зависит от целей разработки описания архитектуры. Обычно, мы делаем описание архитектуры решения для проекта. Для того, чтоб распланировать фазу «реализация», успешно произвести разработку(доработку) ИТ-систем, осуществить их развертывание и ввод в эксплуатацию. Потому и детализация должна быть достаточной для решения этих задач. Каждый квадратик с архитектурных рисунков превращается в строчку проектного плана, а стрелочки показывают взаимозависимость  работ. Практически как на UML диаграмме развертывания. Зависимость одного компонента от другого говорит о том, что нет смысла приступать к его разработке не дождавшись хотя бы спецификации программного интерфейса от второго компонента. Вообще, все эти квадратики нужны для того, чтоб можно было выделить набор работ, которые можно будет вести параллельно, не таская всех участников проекта на многочасовые совещания. Наличие архитектуры помогает сохранить доверие между командами или индивидуумами, позволяя им действовать независимо друг от друга. Как правило, в отдельный набор задач можно вынести закупку лицензий и оборудования и разработку ПО. Описание процессов позволяет разделить разработку с подготовкой и согласованием инструкций и регламентов. Внутри разработки одна команда идет писать базу данных, другая бизнес-логику, третья – отчетность четвертая интеграцию с внешними источниками и т.д. Если кто-то настаивает на излишней детальности архитектурного описания и не может ответить на вопрос – зачем это нужно, то данного персонажа следует вежливо послать. Можно использовать и более миролюбивую модель процесса проектирования – каждый создает свой раздел документа, а архитектор сводит все в единое целое. В общем, конечно, замечания довольно поверхностные. Кому-то они могут показаться банальными (но тогда возьмите и допишите в эту заметку свой раздел). Но, если не следовать хотя бы этим рекомендациям, смысла в проектировании ИТ-решений будет не много

Ссылки по теме:

• Роль ИТ-архитектора в организации
• Интеграция новых приложений в корпоративный ИТ-ландшафт
• Software product management (3) Change management
• О вреде проектного управления

Картинка взята с сайта: http://www.uml-diagrams.org/

Практический пример — Solutioned

СОДЕРЖАНИЕ

1. Введение
2. Архитектура решений
3. Стратегический уровень
4. Бизнес -слой
5. Данные и прикладные уровни
6. .

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

   Как и в предыдущей статье, для иллюстрации дизайна мы будем использовать вымышленную кадровую компанию Demo Staffing Company Inc. Кратко напомним, что бизнес-модель Demo Staffing Company Inc. основана на предоставлении талантливых кандидатов крупным корпоративным клиентам. Клиенты обратились бы к компании со своими потребностями, и компания использовала бы свою сеть, чтобы соответствовать этим потребностям с кандидатами. Для роста своего бизнеса компания должна максимально удовлетворять своих клиентов, чтобы укрепить свой бренд в высококонкурентной отрасли. Машинное обучение и анализ данных — это один (1) из четырех (4) бизнес-процессов, которые компания определила как ключевые для достижения своей цели.

   Архитектура решения

   Что это такое и почему вас это должно волновать?

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

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

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

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

   Уровень стратегии

   Рис. 1. Уровень стратегии, показывающий ресурс ИТ-организации

   При обсуждении архитектуры решения для бизнес-процессов машинного обучения и анализа данных мы очень кратко рассмотрим уровень стратегии. Слой мотивации, который обычно предшествует слою стратегии, не будет включен, но вместо этого подробно обсуждается в эталонной архитектуре. Уровень стратегии здесь сильно сокращен, показывая только один (1) ресурсный элемент. Это делается исключительно для того, чтобы показать, какой ресурс назначен обсуждаемому бизнес-процессу в этой архитектуре решения. Другие элементы (также включенные в эталонную архитектуру), такие как направления действий и возможности, которые имеют отношения назначения и реализации соответственно, снова удалены для краткости.

   Бизнес-уровень

   Рис. 2. Бизнес-уровень, показывающий роль и связанный с ним процесс

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

   Уровень данных и приложений

   Рис. 3. Уровень данных и приложений, показывающий элементы, характерные для машинного обучения и аналитики

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

   Давайте подробно рассмотрим, как служба приложения доставляется в бизнес-процесс.

   1. Поток начинается с подачи заявки в форме подачи резюме на веб-сайте Demo Staffing Company Inc. Это триггерное событие, указывающее на то, что кандидат заинтересован в поиске подходящей должности у одного из клиентов компании.
   2. Событие запускает процесс приложения, который обслуживается службой приложения под названием «Выбор кандидата и роли».
   3. Выбор роли кандидата осуществляется путем совместной работы, состоящей из двух компонентов – «Анализ данных о роли должности» и «Предсказание оптимального соответствия роли должности». Эти компоненты выполняют два различных действия. Сначала для анализа имеющихся данных, а затем для использования этого анализа для оптимального подбора должностных ролей.
   4. Оба вышеперечисленных компонента зависят от наличия данных о доступных кандидатах, частью которых будет вновь представленное резюме, и доступных должностях, предоставляемых клиентами, которые необходимо заполнить.

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

   Технологический уровень

   Рис. 4. Технологический уровень, показывающий инструментирование в облаке

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

   Сразу видно, что подобно тому, как уровень данных и приложений предлагает услуги бизнес-уровню, технологический уровень, в свою очередь, предлагает услуги уровню данных и приложений. Услуга «Наука о данных» фактически состоит из двух подуслуг: «Инфраструктура как услуга (IaaS)» и «База данных как услуга (DbaaS)». Они реализуются посредством двух (2) технологических коллабораций: «Управляемые вычисления в облаке» и «Управляемые контейнеры в облаке». Сообщение здесь состоит в том, что оба эти элемента представляют собой множество систем, сотрудничающих для предоставления одного технологического элемента.

   Совместная работа над управляемыми вычислениями упрощена, чтобы показать поперечное сечение одного узла, «Вычислительного сервера обработки данных». Это то, что на самом деле делает работу по предоставлению услуг по науке о данных. Разворачиваем элементы, из которых состоит этот узел. Начиная с вершины стека и двигаясь вниз, мы видим язык программирования R, работающий на Apache Hadoop, который, в свою очередь, работает на Linux. Управляемые вычисления также предоставляют некоторые технологические функции, которые могут быть полезны компании. К ним относятся высокая доступность, автоматическое масштабирование и распределенные вычисления по требованию. Сообщение от этого сотрудничества заключается в том, что компания может предоставить вычислительные возможности, управляемые поставщиком, который предоставляет полезные встроенные функции, которые ей не нужно развертывать и управлять ими самостоятельно.

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

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

   Собираем все вместе

   Как и в случае с эталонной архитектурой, давайте теперь представим полный проект, обсудив составные части. Опять же, это только один (1) из четырех (4) бизнес-процессов, которые стали бы архитектурами решений из эталонной архитектуры. Подобно эталонной архитектуре, здесь показаны отношения, существующие между самими слоями.

   Рис. 5. Полная архитектура решения для машинного обучения

   Спасибо за внимание.

   Ссылки

   • https://pubs.opengroup.org/architecture/togaf91-doc/arch/index.html
   • https://www.gartner.com/en/information-technology/glossary/enterprise-architecture -ea
   • https://www.opengroup.org/togaf

   Нравится:

   Нравится Загрузка…

   Простой метод создания полезных диаграмм архитектуры решения | Туан Ле

   Будучи архитектором решений в течение последних 15 лет, я действительно понимаю ценность полезной схемы архитектуры решения как эффективного визуального средства для определения и описания архитектуры системы, поставляемой в контексте конкретного решения в соответствии с Википедия.

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

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

   Существует несколько подходящих инструментов для построения диаграмм, как онлайн, так и оффлайн, Visio, LucidChart, Gliffy, Creately и многие другие. Однако я бы рекомендовал использовать Microsoft PowerPoint в качестве основного инструмента по следующим причинам:0003

   • Повторное использование : Если вы создадите полезную диаграмму, другие захотят повторно использовать ее в том же проекте для других целей или в других проектах. Предоставление общего доступа к архитектуре вашего решения в формате PowerPoint значительно упростит редактирование другим пользователям, поскольку PowerPoint — это универсальное продуктивное программное обеспечение, которое есть у каждого.
   • Краткость : Вместо того, чтобы иметь неограниченный холст для рисования, вам нужно будет ограничить свою диаграмму одним слайдом с помощью PowerPoint. Таким образом, вам нужно будет выбрать правильный уровень детализации для архитектуры решения, что заставит вас сосредоточиться на сути вашего решения.
   • Гибкость : PowerPoint дает вам возможность использовать любые формы и изображения, которые вам нужны. Обычно я использую стандартные фигуры PowerPoint вместе со значками/логотипами, загруженными из Интернета. Эти изображения могут удобно вписаться в диаграмму, если они имеют прозрачный фон, что можно быстро сделать с помощью функции волшебной палочки в Paint.NET (бесплатный редактор изображений).

   По сути, работа архитектора решений заключается в анализе бизнес-требований и разработке технологического решения, отвечающего этим требованиям. Бесспорно, архитектура решения закладывает прочную основу для всех успешных проектов разработки.

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

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

   Бизнес-требования для решения электронной коммерции B2C относительно просты. Клиент просто хочет иметь сайт электронной коммерции, где потребители могут видеть свои продукты и совершать покупки онлайн. Они также хотят сделать продукты доступными в поиске Google и иметь возможность ремаркетинга потребителей через платформу Criteo, чтобы привлечь больше трафика на сайт. И, конечно же, они настаивают на том, чтобы новый сайт электронной коммерции был интегрирован с существующей ERP, CRM и системой автоматизации маркетинга.

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

   Бизнес

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

   Иконки пользователей

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

   Обозначения для функциональных возможностей

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

   Информация

   Обозначения потока данных

   В архитектуре решения информация относится к данным, передаваемым между различными строительными блоками. Сначала вам нужно определить важные объекты данных в вашем решении. Например, в решении для электронной коммерции это каталог продуктов, цены на продукты, запасы, данные о клиентах и ​​​​заказы. Опять же, вы можете использовать стрелки для обозначения данных, следующих за аннотированными именами объектов данных. Эти стрелки должны указывать направления потоков данных из одной системы в другую. Эти перемещения данных помогут вам определить требования к интеграции.

   Технология

   Системные обозначения

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

   • самой системы электронной коммерции B2C.
   • Внутренняя ERP, CRM и система автоматизации маркетинга, как указал клиент.
   • И другие внешние системы, включая систему логистики, платежный шлюз и Google Analytics, Google Shopping и Criteo.

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

   Теперь, когда мы определили, что включить в диаграмму архитектуры решения, давайте обсудим, как их объединить.

   Шаги

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

   Компоновка

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

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

   Оптика

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

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

   Артефакт

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

   Диаграмма архитектуры решения электронной коммерции B2C

   В разработке программного обеспечения унифицированный язык моделирования (UML) является стандартным способом визуализации проекта системы. Архитекторы программного обеспечения и технические архитекторы широко используют UML для моделирования системы, независимой от языка платформы.

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

   Для меня, как для архитектора решений, самые приятные моменты — это когда ключевая заинтересованная сторона похлопывает меня по плечу и искренне говорит: «Я верю, что вы хорошо разбираетесь в этом» в конце презентации, в которой представлена ​​полезная архитектура решения. диаграмма в качестве фокуса для обсуждения. Я считаю, что этот простой метод помогает мне создавать возможности для наслаждения многими из этих моментов.

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

   Архитектор решений: роль и обязанности

   Время чтения: 12 минут

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

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

   Кто такой архитектор решений?

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

   Архитектор решений отвечает за руководство практикой и представление общего технического видения конкретного решения.

   Хотя практикой можно управлять внутри компании, есть компании, которые предоставляют консультации по архитектуре решений в виде определенного набора услуг.

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

   Что такое архитектор решений и чем эта роль отличается от архитектора программного обеспечения и архитектора предприятия (а также подпишитесь на наш канал, так как мы продолжим выпускать обучающие видеоролики)

   Архитектор предприятия, архитектор решений и технический архитектор

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

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

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

   Архитектура решения в контексте предприятия и технической архитектуры

   Кто такой архитектор предприятия?

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

   Архитектор предприятия имеет самое широкое представление о текущем состоянии архитектуры и целей компании. Именно этот эксперт отвечает за создание стратегического плана внедрения технических изменений. Этот человек тесно сотрудничает с руководителями высшего звена и лицами, принимающими решения, поскольку он или она демонстрирует им коммерческую ценность предлагаемых технических инициатив.

   Кто такой программный или технический архитектор?

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

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

   Кто такой архитектор инфраструктуры?

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

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

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

   Архитектура решения и ее основные процессы

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

   Согласование решений с корпоративной средой

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

   Удовлетворение требований всех заинтересованных сторон

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

   Учет ограничений проекта

   Каждый проект имеет свои ограничения, обычно называемые ограничениями. К ним относятся:

   • технология
   • риски
   • прицел
   • стоимость
   • качество
   • время
   • ресурсов

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

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

   Выбор стека технологий проекта

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

   Соответствие нефункциональным требованиям

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

   Поскольку мы обсудили общие цели внедрения архитектуры решения, давайте разобьем их на конкретные обязанности и базовые наборы навыков.

   Описание роли и обязанностей архитектора решений

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

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

   Обязанности архитектора решений непосредственно вытекают из процессов на практике:

   • Анализ технологической среды
   • Анализ специфики предприятия
   • Анализ и документирование требований
   • Настройка структуры сотрудничества
   • Создание прототипа решения
   • Участие в отборе технологий
   • Управление разработкой решения
   • Поддержка управления проектами

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

   Набор навыков и опыт архитектора решений

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

   Распределение ролей архитектора решений

   Техническое образование и опыт

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

   • ИТ-архитектура, инфраструктура и разработка облачных вычислений
   • Проектирование инженерной и программной архитектуры
   • Бизнес-анализ
   • DevOps
   • Управление проектами и продуктами

   Отличные коммуникативные навыки

   Важнейшей частью компетенции архитектора решений является общение. Учитывая, что эта роль предполагает ведение переговоров с заинтересованными сторонами, понимание потребностей всех сторон, управление рисками и поставку продукта, отсутствие навыков общения может стать настоящим узким местом. Эта должность требует тесного сотрудничества с архитекторами предприятий и программного обеспечения, бизнес-аналитиками и проектными группами. Итак, опытный архитектор решений должен уметь слушать, советовать, сопереживать и объяснять.

   Глубокие аналитические способности

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

   Навыки управления проектами и ресурсами

   Хотя архитектор решений не принимает непосредственного участия в управлении проектом, учет сроков и предоставленных ресурсов неизбежен. Архитекторы решений должны иметь возможность принимать решения о том, какие решения выгодны, а какие бесполезны в данной ситуации. Они должны быть ориентированы на бизнес-результаты и понимать, как их достичь в соответствии с заданными сроками и ресурсами.

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

   Сертификация архитекторов решений

   Сертификации предназначены для проверки навыков и опыта архитекторов решений. Они оценивают свои знания, способности и опыт. Таким образом, наличие одной или нескольких учетных данных доказывает владение экспертом определенными навыками.

   Большинство сертификационных платформ, помимо самого экзамена, предлагают учебные курсы, учебные материалы и практические тесты. Другие ресурсы также могут быть полезны для подготовки и практики, например Udemy, Coursera или MeasureUp. Однако экзамен можно сдавать и без предварительной подготовки — все, что требуется, — это глубокое знание архитектурных концепций и принципов и большой практический опыт работы в отрасли.

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

   Сертификация архитектора решений AWS

   Программа AWS Certified Solutions Architect предлагает сертификаты младшего и профессионального уровней в зависимости от вашего опыта. Оба они нацелены на архитекторов, которые работают с технологиями AWS для создания и развертывания приложений и систем.

   Экзамен AWS Certified Solutions Architect — Associate занимает 130 минут и стоит 150 долларов США. Amazon рекомендует кандидатам иметь не менее 1 года практического опыта перед сдачей теста. Вот список основных предметных областей этого экзамена:

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

   Сертифицированный архитектор решений AWS — профессиональный экзамен предназначен для старших архитекторов с 2 или более лет опыта и удостоверения младшего специалиста. Это занимает 180 минут и стоит 300 долларов. Вот схема содержания:

   Список основных доменов контента и их веса, источник: Руководство по экзамену

   Сертификаты AWS действительны в течение 3 лет, после чего обладатели учетных данных должны пройти повторную сертификацию, чтобы подтвердить свой постоянный опыт и знание новейшие технологии и лучшие практики AWS.

   Сертификация архитектора решений Azure

   Корпорация Майкрософт имеет различные учетные данные для архитекторов решений, наиболее известным из которых является сертификат Microsoft Certified: Azure Solutions Architect Expert. Это для кандидатов, специализирующихся на решениях, работающих в Microsoft Azure, и обладающих глубокими знаниями об инфраструктуре Azure.

   Сертификацию эксперта по архитектуре решений Azure можно получить после сдачи экзамена: AZ-305: Проектирование инфраструктурных решений Microsoft Azure. Цена зависит от страны, в которой проводится экзамен (165 долларов США для США).

   Вот обзор навыков, измеряемых этими тестами. Вкратце, AZ-305 ориентирован на технические задачи, такие как:

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

   Содержание АЗ-305 оценивает такие навыки как:

   • контроль проектирования,
   • дизайн и безопасность,
   • хранилище проектных данных,
   • проектирование непрерывности бизнеса и
   • проектная инфраструктура.

   Сертификация ITIL

   ITIL — это признанный в отрасли набор квалификаций, включающий 5 уровней. Высшей квалификацией является ITIL Master для тех специалистов, которые работают в области управления ИТ-услугами и имеют большой опыт работы с практиками ITIL. Это не совсем ролевая сертификация специально для архитекторов решений, но, поскольку ITIL является популярной структурой управления, человек, усвоивший ее принципы, будет ценным активом на любой управленческой должности.

   В описании указано, что для получения сертификата вы должны быть в состоянии « объяснить и обосновать, как вы лично выбрали и применили ряд знаний, принципов, методов и методов из ITIL Framework и поддерживающих методов управления для достижения желаемого бизнеса. результаты одного или нескольких практических заданий. ” Таким образом, для этого экзамена не существует учебного курса или фиксированной программы, поскольку каждый кандидат будет проверен в рамках своего уникального опыта.

   Наличие сертификата ITIL Expert является необходимым условием для получения этих учетных данных. Кандидат также должен иметь более 5 лет опыта работы на руководящих, управленческих или консультативных должностях высокого уровня. Как только эти условия будут выполнены, претендент должен будет зарегистрироваться в PeopleCert (утвержденный экзаменационный институт Axelos), заполнить заявку и представить свое резюме. Затем необходимо представить предложение по улучшению бизнеса вместе с рабочим пакетом, демонстрирующим практические навыки кандидата в применении принципов ITIL в реальных бизнес-кейсах. После этого соискатели должны будут успешно пройти собеседование с оценочной комиссией, где им будет задан вопрос об их опыте.

   Стоимость как экзамена, так и учебных курсов зависит от местоположения.

   Сертификация облачного архитектора Google

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

   Экзамен длится 2 часа, регистрационный взнос составляет 200 долларов США. Google рекомендует иметь как минимум 3 года опыта, прежде чем пытаться пройти тест. Также важно помнить, что требуется переаттестация каждые два года. Доступно руководство по экзамену (а также учебные материалы и примеры вопросов), в котором перечислены 6 аспектов экзамена:

   1. Проектирование и планирование архитектуры облачных решений;
   2. Управление и предоставление инфраструктуры решения;
   3. Разработка для обеспечения безопасности и соответствия требованиям;
   4. Анализ и оптимизация технологий и бизнес-процессов;
   5. Управление внедрением; и
   6. Обеспечение надежности решений и операций.

   Когда компании требуется консультация по архитектуре решения

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

   Давайте рассмотрим случаи, когда рекомендуется консультация по архитектуре решения:

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

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

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

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

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

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

   Архитектура решения является основой любого ИТ-проекта, независимо от того, применяете ли вы эту практику на самом деле или нет. Преднамеренно внедряя архитектуру решения, вы создаете структуру, которая согласовывает технологии, ресурсы и навыки с определенными бизнес-целями.

   Прежде чем рассматривать архитектуру решения, мы рекомендуем изучить структуры архитектуры предприятия, которые сочетают в себе уровни решения и предприятия.

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

   Примеры эталонной архитектуры и рекомендации

   AWS Well-Architected

   • AWS Well-Architected Framework
   • Инструмент AWS Well-Architected
   • Объективы AWS Well-Architected
   • Лаборатория AWS Well-Architected

   Эталонные архитектуры

   • Аналитика и большие данные
   • Вычисления и высокопроизводительные вычисления
     
   • Базы данных
   • Просмотреть все схемы архитектуры

   Ознакомьтесь с нашим контентом

   Центр архитектуры AWS предоставляет эталонные схемы архитектуры, проверенные архитектурные решения, рекомендации Well-Architected, шаблоны, значки и многое другое. Это экспертное руководство было предоставлено экспертами по облачной архитектуре из AWS, в том числе архитекторами решений AWS, консультантами по профессиональным услугам и партнерами.
   

   Фильтровать по:

   Очистить все фильтры

   Фильтр

   Фильтр

   Закрывать Применить фильтры

   Фильтр

   Фильтр

   Закрывать Применить фильтры

   Элементы, соответствующие выбранным критериям, не найдены.

   Категории технологий

   Аналитика и большие данные

   Создавайте безопасные, надежные и экономичные архитектуры обработки данных.

   Compute & HPC

   Узнайте, как разрабатывать, развертывать, запускать и масштабировать свои приложения.

   Контейнеры

   Узнайте о наиболее безопасном, надежном и масштабируемом способе запуска контейнеров.

   Оптимизация затрат

   Узнайте, как постоянно оптимизировать свои расходы.

   Базы данных

   Выберите базу данных, соответствующую вашему варианту использования и схемам доступа.

   Вычисления для конечных пользователей

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

   IoT

   Научитесь подключать устройства и собирать, хранить и анализировать данные устройств.

   Машинное обучение

   Создавайте эффективные и действенные архитектуры машинного обучения (ML).

   Управление и управление

   Узнайте, как быстрее и надежнее создавать и доставлять продукты с помощью AWS.

   Microsoft

   Ознакомьтесь с рекомендациями по созданию и запуску приложений Microsoft.

   Миграция

   Узнайте, как перенести существующие приложения в AWS.

   Работа в сети и доставка контента

   Научитесь подключать устройства и собирать, хранить и анализировать данные устройств.

   Безопасность, идентификация и соответствие требованиям

   Узнайте, как достичь целей безопасности и соответствия требованиям с помощью инфраструктуры и сервисов AWS.

   Serverless

   Научитесь создавать и запускать приложения и серверные службы без серверов.

   Хранение

   Разработка надежных, масштабируемых и безопасных архитектур хранения данных.

   Помогла ли вам эта страница?

   Да

   Нет

    Отзыв

   Закрыть

   Спасибо за отзыв

   Мы рады, что эта страница помогла вам. Хотите поделиться дополнительной информацией, чтобы помочь нам продолжать совершенствоваться?

    Отзыв

   Закрыть

   Спасибо за ваш отзыв

   Нам жаль, что эта страница вам не помогла. Хотите поделиться дополнительной информацией, чтобы помочь нам продолжать совершенствоваться?

    Отзыв

   Войдите в консоль

   Узнайте об AWS

   • Что такое AWS?
   • Что такое облачные вычисления?
   • AWS Разнообразие, равенство и инклюзивность
   • Что такое DevOps?
   • Что такое контейнер?
   • Что такое озеро данных?
   • Облачная безопасность AWS
   • Что нового
   • Блоги
   • Пресс-релизы

   Ресурсы для AWS

   • Начало работы
   • Обучение и сертификация
   • Портфолио решений AWS
   • Архитектурный центр
   • Часто задаваемые вопросы по продуктам и техническим вопросам
   • Аналитические отчеты
   • Партнеры AWS

   Разработчики на AWS

   • Центр разработчиков
   • SDK и инструменты
   • . NET на AWS
   • Python на AWS
   • Java на AWS
   • PHP на AWS
   • JavaScript на AWS

   Помощь

   • Свяжитесь с нами
   • Подайте заявку в службу поддержки
   • Центр знаний
   • AWS re: Сообщение
   • Обзор поддержки AWS
   • Юридический
   • Карьера в AWS

   Amazon является работодателем с равными возможностями: Меньшинства / Женщины / Инвалидность / Ветеран / Гендерная идентичность / Сексуальная ориентация / Возраст.

   • Конфиденциальность
   • |
   • Условия сайта
   • |
   • Настройки файлов cookie
   • |
   • © 2022, Amazon Web Services, Inc. или ее дочерние компании. Все права защищены.

   Поддержка AWS для Internet Explorer прекращается 31. 07.2022. Поддерживаемые браузеры: Chrome, Firefox, Edge и Safari. Узнать больше »

   Как создавать важные архитектурные решения

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

   Используйте свои усилия для предварительного анализа проблем проектирования

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

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

   Важность проектирования для основной проблемы

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

   Одно из решений проблемы с акустикой в ​​банке — создать отдельную, но примыкающую комнату, куда банкиры и клиенты могли бы прийти для обсуждения. Однако это решение одного из банковских «симптомов» корневой проблемы. Это решение не решает основной проблемы, когда все сотрудники банка должны работать в неудобном пространстве. Как видите, оформление отдельной и смежной комнаты — не верный дизайнерский путь. Вместо этого, если кто-то спроектирует корень проблемы, банк сможет функционировать на значительно улучшенных уровнях сотрудников и клиентов.

   Раскрытие потенциала вашего дизайна

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

   Изображение предоставлено: © stockpics | Fotolia

   Ваш следующий шаг:

    

   БОЛЕЕ 6700 ПОДПИСЧИКОВ

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

   ПРИСОЕДИНЯЙСЯ СЕЙЧАС

   7 образцов эталонной архитектуры для инфраструктурных проектов

   Опубликовано: 11 мая 2022 г. | | по Эрик Д. Шабелл (Навигатор, Red Hat)

   Изображение

   ^{Фото Шейна Раунса на Unsplash}

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

   В течение последних нескольких лет команда Red Hat Portfolio Architecture занимается разработкой эталонных архитектур на основе реальных сценариев использования клиентов в различных отраслях. У нас есть несколько критериев для разработки и проверки коллекции архитектур перед ее публикацией, которые вы можете прочитать в моей вводной статье о портфолио архитектуры.

   Мы публикуем эти архитектуры для всеобщего использования в нашем Red Hat Portfolio Architecture Center и репозитории примеров портфолио архитектуры.

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

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

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

   От облака до периферии

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

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

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

   Этот вариант использования обеспечивает облачные возможности в периферийных местоположениях.

   [ Узнайте, как модернизировать ИТ с помощью управляемых облачных сервисов. ]

   Центр обработки данных до периферии

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

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

   Вариант использования приближает вычисления к периферии за счет мониторинга потенциальных проблем с газопроводами на периферии.

   Гибридное управление несколькими облаками с помощью GitOps

   Гибридное управление несколькими облаками с архитектурой GitOps обеспечивает стабильную и простую контейнерную платформу для разработчиков и инженеров, которая безопасна, поддерживает гибридную среду и работает в нескольких облачных решениях. Он использует автоматизированный подход «инфраструктура как код», который управляет версиями и обеспечивает развертывание в соответствии с предоставленными конфигурациями.

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

   Вариант использования управляет жизненными циклами гибридных и многооблачных кластеров, безопасными конфигурациями и учетными данными. Он использует GitOps для подхода «инфраструктура как код». Он также обеспечивает межкластерное управление и управление жизненным циклом приложений.

   [ Узнайте больше, загрузив управляемую событиями архитектуру для гибридного облака. ]

   Модернизация интерфейса SCADA

   Архитектура модернизации интерфейса SCADA (диспетчерское управление и сбор данных) нацелена на поставщиков электроэнергии в Северной Америке, стремящихся обеспечить соответствие нормам Североамериканской корпорации по обеспечению надежности электроснабжения (NERC) путем модернизации интерфейсов между их бизнес-приложениями и их системами SCADA. Эта модернизация также обеспечивает лучшее потребление информации, которое можно сочетать с искусственным интеллектом (ИИ), машинным обучением (МО) и инструментами управления решениями для удовлетворения потребностей клиентов.

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

   Вариант использования обеспечивает интерфейсы с системами SCADA, соответствующие требованиям NERC, создавая различные уровни шлюзов API для защиты бизнес-сервисов в зависимости от сетевых зон.

   Архитектуры 5G

   5G — это новейшая разработка в области беспроводных мобильных технологий, целью которой является предоставление пользователям возможностей полного погружения и сверхнадежная связь между устройствами с малой задержкой. В основе каждой сети 5G лежит ядро ​​5G (5GC).

   [ Чтобы узнать больше о 5G, прочитайте статью Расширение 5G с помощью архитектуры 5G Open HyperCore. ]

   Ядро Telco 5G: локально

   Архитектура ядра 5G Telco (локально) представляет 5G Core как набор дезагрегированных облачных приложений, которые взаимодействуют внутри и снаружи через четко определенные стандартные интерфейсы. Каждый компонент 5GC реализован как приложение на основе контейнера и называется облачной сетевой функцией (CNF).

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

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

   Telco 5G с гиперскейлерами

   Архитектура Telco 5G с гиперскейлерами описывает решение 5G, основанное на технологиях с открытым исходным кодом, которое работает на любом гиперскейлере.

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

   Вариант использования — создание адаптируемых инфраструктурных услуг по требованию для 5G Core, которые могут предоставляться в различных сценариях использования с минимальными капитальными и эксплуатационными расходами (CAPEX и OPEX).

   Telco 5G: сети радиодоступа

   Архитектура сетей радиодоступа Telco служит сценарию использования, основанному на том факте, что цифровая трансформация мобильных сетей ускоряется, а облачность увеличивается. Решения для сетей радиодоступа (RAN) теперь используют преимущества облачных вычислений.

   Изображение

   Щелкните изображение, чтобы увеличить его (Эрик Шабелл, CC BY-SA 4.0)

   Подробнее

   Это семь из многих эталонных архитектур, уже опубликованных архитекторами портфолио Red Hat, и мы продолжим добавлять новые по мере их завершения.

   No related posts.