Масштабируемость 1s only что это

Что такое Intel Xeon Scalable?

Обновление модельного ряда процессоров Intel Xeon в этом году стало самым значительным событием на рынке серверных платформ Intel начиная с 2011 года – тогда были выпущены так привычные нам линейки Е3, Е5, Е7. И вот снова четырехзначные индексы, вдобавок серии Platinum, Gold, Silver и Bronze, а также обобщающий бренд Xeon Scalable. С первой попытки оказалось трудно понять логику происходящего, и в заинтересованных кругах подвис вопрос: зачем это вообще понадобилось? Об идеологической подоплеке создания семейства Xeon Scalable и самых интересных новшествах в нем мы расскажем в этом посте.

Быстрее, совместимее, гибче

Итак, для начала идеологический аспект. В последние годы жизнь в семействе Intel Xeon шла по накатанному. Постепенно щелкали счетчики поколений, происходило это несинхронно и беспорядочно. Каждая линейка Е3, Е5, Е7 жила своей жизнью, в своем сокете, несовместимая с соседями. Сервера проектировались под конкретную линейку и только под нее.

Шло время, Е7 менялись медленно, Е3 побыстрее, но все равно значительно, на несколько лет, опаздывали по техпроцессу от Intel Core. А нереализованный потенциал – это упущенная выгода. Проанализировав ситуацию, в Intel выделили ключевые проблемы, которые должен решить выход принципиально новых Xeon:

Какие области более всего нуждаются в комплексах с подобными характеристиками? Самые динамично развивающиеся, такие как облачные хранилища и сервисы, программно определяемые системы и так далее. Ну а что делать, если требуются сервера под традиционные нагрузки, скажем, для телекома (к слову сказать, показывающего в последнее время отрицательную динамику роста серверных мощностей)? Тогда Xeon Scalable можно считать следующим поколением Intel Xeon, партнеры Intel без проблем предоставят вам консультацию о соответствии старых и новых линеек.

Новые возможности

Теперь о функциональных новшествах Xeon Scalable – они также служат цели превращения платформы в идеально масштабируемую ноду.

Scalable и не только

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

Сервера с Intel Scalable уже доступны для заказа. Вот, например, HP DL360 Gen10. Обратите внимание, если предыдущее поколение DL360 строилось только на процессорах Intel Xeon E5 (как и положено двухсокетному серверу), то теперь в вашем распоряжении весь набор линеек от 3000 до 8000 (от Bronze до Platinum). Вот такая скалабильность получается.

Источник

Поиск и решение проблем масштабируемости на примере многоядерных процессоров Intel Core 2 (часть 1)

Что есть масштабируемость?

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

События производительности процессора на основе микроархитектуры Intel Core2 предоставляют нам удобные метрики для этих целей. Каждое ядро имеет Блок Мониторинга Производительности (Performance Monitoring Unit или PMU), а событие CPU_CLK_UNHALTED.CORE позволяет определить число рабочих циклов на каждом ядре. Если для сбора информации используется VTune™ Performance Analyzer, то это число суммируется для всех ядер, исполнявших интересующий нас процесс. То есть это число есть количество эффективных циклов потраченных на исполнение приложения. Назовем это число «effective_cycles».

Полезной особенностью PMU является возможность сравнивать на каждом цикле значение события с некоторым заданным числом (cmask) и определять, является ли оно большим или равным (inv=0) или же оно меньше этого числа (inv=1). Если такое условие задано, PMU будет считать циклы только в случае его соблюдения. Однако, это возможно только для счетчиков общего назначения. Фиксированные счетчики, например, для событий CPU_CLK_UNHALTED.CORE, INST_RETIRED.ANY и CPU_CLK_UNHALTED.REF, не могут подвергаться этой операции. Если значение события CPU_CLK_UNHALTED.CORE_P (обобщенная версия счетчика рабочих циклов) сравнивать с числом 2 с условием «менее чем» (inv=1), то счетчик будет считать все циклы. Если это число просуммировать для всех процессов и поделить на количество ядер в системе, мы получим полное время исполнения процесса. Назовем это число «total_cycles».

Для обеспечения корректности полученных значений необходимо, что бы функция Speed Stepping была отключена в BIOS и ОС, иначе незагруженные ядра могут работать на пониженной частоте, что исказит полученное значение полного времени. Отношение effective_cycles/total_cycles будет равняться числу использовавшихся ядер для отлично масштабируемого кода, и равняться 1 для абсолютно последовательного кода. Причем результат не зависит от того, какая часть из всех ядер системы была задействована во время исполнения. Однако ценность этой техники может быть нивелирована, если в коде встречаются пожирающие процессорное время циклы активного ожидания, так что циклы ожидания должны быть реализованы корректно. Для более детального анализа рекомендуется использовать Intel Thread Profiler.

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

Ограниченность ресурсов

Последний компонент списка имеет несколько иное влияние на производительность, чем все остальные, так как синхронизация потоков (threads) и процессов зависит от блокируемого доступа к линиям КЭШа. Различие это наиболее очевидно с той точки зрения, что более быстрый / более объемный кэш не всегда способен обойти влияние падения масштабируемости, как в случае с другими элементами этого списка.

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

Пропускная способность

Чтобы понять какой вклад в падение производительности вносит трафик по шине, необходимо определить, какой, собственно, трафик проходит по шине во время выполнения программы (суммарный и по отдельным компонентам) и какова пиковая пропускная способность платформы используемой при анализе. Пиковая пропускная способность платформы зависит от большого числа сторонних факторов. Это и конфигурация аппаратных блоков предвыборки данных (hardware prefetchers), и количество, тип и расположение в слотах планок оперативной памяти, и частота системной шины, частота процессора, и условия, позволяющие достигнуть когерентности КЭШей. Поэтому ни одна метрика не может считаться определяющей пропускную способность платформы на основе Intel Core 2. Единственный приемлемый метод определить ее – провести синтетический тест пропускной способности. Одиночный длительный цикл алгоритма TRIAD похоже наилучшим образом подходит для этих целей. Так как предел пропускной способности для многоядерного расчета скорее всего будет отличен от одноядерного, вышеозначенный тест должен поддерживать параллельный счет либо за счет потоков, либо за счет разбиения на отдельные процессы.

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

В большинстве случаев компонент ifetch (instruction fetch, выборка инструкции) маловажен, особенно в ситуации с пиковой пропускной способностью, а, следовательно, может быть проигнорирован.

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

Или напрямую, как количество байт переданных по шине в составе кэш-линий:

Удобной метрикой в этом случае является просто количество кэш-линий на цикл, так как аппетит N параллельных версий данного приложения / потока составит N раз от этого значения. Так что если предел платформы определен в этих значениях, наиболее вероятная загруженность шины при параллельном счете может быть легко определена во время анализа единичного потока.
События BUS_TRANS_* можно использовать иерархически, чтобы вычленить компоненты, использующие шину. Их краткое описание представлено в нижеследующей таблице, а также они очень подробно разобраны в онлайн справке VTune Performance Analyzer.

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

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

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

Источник

Масштабируемость: что это такое?

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

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

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

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

В качестве оценки предельной производительности карточки можно использовать известные характеристики количества треугольников, которые она может обработать в секунду, и скорость закраски (fill-rate), т.е. количество текстурированных и отфильтрованных пикселов, выводимых в одну секунду. Возьмем для примера две карточки: 3Dfx Voodoo и nVidia Riva TNT.

Как видим, теоретические данные очень неплохо согласуются с практическими (эти параметры приблизительно соответствуют Quake 2).

Что следует из этих цифр? Очень простой вывод. Начиная с какого-то уровня, производительность 3D-ускорителя уже не играет роли (глазу все равно, 160 или 60 fps он видит). Все теперь упирается в процессорную зависимость, т.е. в то, какой процессор нужен, чтобы достичь подобных пиковых значений. Вот почему я с большим скепсисом читаю характеристики вновь появляющихся 3D-ускорителей. Также легко видеть, что приведенные ускорители (как и подавляющее большинство остальных) ограничены именно скоростью закраски, тогда как для процессора основная нагрузка исходит от процесса геометрических преобразований, т.е., усилия разработчиков сосредоточены несколько не в том месте, где надо бы.

Источник

Масштабируемость 1s only что это

Облачные сервисы — адаптивность и масштабируемость

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

Услуги связи — поддержка 5G

Высокопроизводительные вычисления — ускорьте аналитику

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

Искусственный интеллект — оптимизация для глубинного обучения

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

Информация о продукте и производительности

Заявление об ускорении рабочих нагрузок хранилища OLTP до 5 раз: 1 узел, 4 процессора Intel® Xeon® E7-4870 на платформе Emerald Ridge с совокупной емкостью памяти 512 ГБ, ОС Oracle Linux* 6.4 с использованием Oracle 12c* с 800 работающими хранилищами. Эталонный тест: HammerDB, показатель: 2.46322e+006 (чем выше, тем лучше) и 1 узел, 4 процессора Intel® Xeon® 8180 класса Platinum на платформе Lightning Ridge SKX с совокупной емкостью памяти 768 ГБ, ОС Red Hat Enterprise Linux* 7.3 с использованием Oracle* 12.2.0.1 (включая базу данных и грид-вычисления) с 800 хранилищами. Показатель: 1.2423e+007.

Платформа: 2 процессора Intel® Xeon® E5-2697 v2 с частотой 2,70 ГГц (12 ядер), технология HT включена, режим Turbo включен, для управления масштабированием установлен режим «производительность» с помощью драйвера intel_pstate, оперативная память: 256 ГБ DDR3-1600 ECC. ОС CentOS* Linux версия 7.3.1611 (основная), ядро Linux 3.10.0-514.21.1.el7.x86_64. Твердотельный накопитель: твердотельный накопитель Intel® серии 520 (240 ГБ, 2,5 дюйма, SATA, 6 Гбит/с, 25 нм, MLC).

Пример оценки снижения совокупной стоимости владения до 65% за 4 года основан на оценке эквивалентных по производительности стоечных систем с использованием виртуализованной рабочей нагрузки консолидации VMware ESXi*. Сравнивались 20 установленных двухпроцессорных серверов с процессором Intel® Xeon® E5-2690 (прежнее название «Sandy Bridge-EP») с запущенным ПО VMware ESXi* 6.0 GA с использованием гостевой ОС RHEL* 6.4 с совокупной стоимостью 919 362 доллара и 5 новых процессоров Intel® Xeon® 8180 класса Platinum (Skylake) с запущенным ПО VMware ESXi* 6.0 U3 GA с использованием гостевой ОС RHEL* 6 (64-разрядная версия) с совокупной стоимостью 320 879 долларов, включая приобретение базового оборудования. Предположительная цена сервера основана на текущих опубликованных розничных ценах двухпроцессорных серверов OEM-производителей с процессорами Intel® Xeon® E5-2690 v4 и двух процессоров E7-8890 v4 в 4-процессорном сервере — цены могут изменяться на основании фактических цен предлагаемых систем.

Источник

Нефункциональные требования: Масштабируемость

Автор: Adam Alami, PhD Fellow, IT University of Copenhagen (перевод с англ.)

ВВЕДЕНИЕ

Нефункциональные требования широко представлены в литературе. Нет недостатка в определениях и примерах нефункциональных требований. Международный институт бизнес-анализа (IIBA) определяет нефункциональные требования следующим образом:

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

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

Условия: они являются внешними или внутренними ограничениями. Внутренние ограничения — это политика и саморегулирование организации, в то время как внешние ограничения — это государственные правила, отраслевые стандараты и другие параметры, определяющие бизнес-среду.

Качества: это бизнес-требования, которые определяют не системное поведение и не связаны с процессом, а являются требованиями к качеству решения.

Примеры:

i) Условия
а. Брендинг,
б. Конфиденциальность данных,
с. Совместимость с PCI;

ii) Качества
а. Доступность,
б. Производительность.

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

ЗАЧЕМ НУЖНЫ «НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ»

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

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

Почему же нефункциональные требования недооцениваются?

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

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

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

ЧТО ТАКОЕ МАСШТАБИРУЕМОСТЬ?

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

1. Физическая масштабируемость

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

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

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

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

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

2. Нематериальная масштабируемость

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

* Новые продукты, которые будут размещаться на одной платформе / решении
* Дополнительные бренды (для мультибрендовых организаций)
* Дополнительные бизнес-процессы

В чем разница между физическим и нематериальным? Хотя оба они могут казаться похожими, они не идентичны. Решение может быть устойчивым физически, но может не поддерживать неосязаемый рост. Например, если объем операций увеличивается, то решение должно быть устойчивым физически. Если бизнес вводит новые продукты, то это классифицируется как неосязаемый рост, и решение должно иметь масштабируемые функции и процессы (не физические) для поддержки этого роста.

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

КАК ОПРЕДЕЛЯТЬ ТРЕБОВАНИЯ К МАСШТАБИРУЕМОСТИ?

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

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

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

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

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

1. Каков текущий объем клиентов, транзакций, счетов и т.д.?
2. Какие объемы ожидаются от работы систем в первый день?
3. Каков ежегодный рост объема (клиентов, транзакций и т.д.), ожидаемый в ближайшие три-пять лет?

Вопрос 1 следует задать для определения текущего состояния.

Вопрос 2 определяет непосредственное требование с первого дня жизни (эксплуатации).

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

1. Решение должно поддерживать ежегодный рост на 10% новых клиентов.
2. Решение должно поддерживать ежегодный рост на 15% от предыдущего количества транзакций.

Однако, в этом примере, я бы предложил дополнительно определить ожидания того, что требование предполагает «поддержку» (т.е. технология не требует каких-либо изменений для обработки роста)?

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

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

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

1. Планирует ли организация выпускать новые продукты (например, мобильные платежи, продукты, подобные Apple Pay или Bitcoin)?
2. Есть ли какие-либо будущие приобретения или слияния с аналогичными предприятиями?
3. Какова стратегия организации (т.е. новые каналы сбыта, выход на новые рынки и т.д.)?

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

1. Решение должно быть в состоянии разместить два разных бренда: Brand A и Brand B.
2. Оба бренда должны иметь возможность использовать одни и те же системы и процессы.

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

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

__________________________________________________________
Автор: Адам Алами, доктор философии, ИТ-университет Копенгагена

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

У него есть ряд академических достижений. Он имеет степень бакалавра по разработке программного обеспечения в Университете Квебека Монреаля (UQÀM) и степень магистра по вычислительной технике в Технологическом университете Сиднея (UTS).

Источник