Основные домены описания архитектуры бизнес модели

Рис.
5.1.
Области, входящие в понятие Архитектуры предприятия

Библиографическое описание:

Михайлов, О. В. Обзор основных элементов архитектуры предприятия / О. В. Михайлов. — Текст : непосредственный // Вопросы экономики и управления. — 2016. — № 3 (5). — С. 83-86. — URL: https://moluch.ru/th/5/archive/31/895/ (дата обращения: 24.03.2023).

Построение архитектуры интеллектуальных транспортных систем

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

Архитектура информационной системы предприятий

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

Информационная архитектура | Статья в журнале…

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

В рамках архитектуры предприятия выделяют модели, принципы и стандарты.

Исследование влияния архитектуры приложений на…

архитектура приложений, инфраструктура предприятия, архитектурный стиль.

Архитектура предприятия представляет собой сложную систему из взаимодействующих IT-ресурсов, их

Ковалев И. В., Голубев И. М., Царев Р. Ю. Модель архитектурной надежности приложений…

Подходы к архитектурному проектированию веб-приложений

Ключевые слова: веб, приложение, архитектура, веб-приложение. Текст аннотации: в рамках данной статьи в краткой форме рассматриваются три подхода к архитектурному проектированию веб-приложений, однако…

Технология разработки функциональной модели архитектуры…

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

Использование шаблона проектирования MVC в разработке…

В процессе проектирования сложных систем, таких как комплексные и интегрированные СЗИ информационных систем (ИС), в большинстве случаев… Особенности реализации MVC-архитектуры в веб-приложениях.

Особенности реализации MVC-архитектуры в веб-приложениях

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

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

Headless-архитектура информационной системы предприятия. информационная система, пользовательский интерфейс, программное обеспечение, данные, подсистема, часть системы, система управления, мастер цеха, баз знаний, XML, SQL, JSON, HTML, API, сеть.

“

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

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

Автор:
П. М. Потеев, В. Г. Рудь

5.1.1 Архитектура: слои и домены

Рисунок 5.1
Архитектура организации

В архитектуру организации входят элементы разной природы, которые показаны на рисунке 5.1:

• структурные элементы — например, подразделения, группы, ИТ-системы, базы данных, станки, конвейеры, офисы, склады;

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

• пассивные элементы в виде документов, объектов данных, цифровых двойников реальности;

• элементы мотивации и целеполагания: цели действий, принципы деятельности, правовые нормы, драйверы рынка и интересы отдельных стейкхолдеров.

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

Типизированные блоки архитектуры называют компонентами, или слоями архитектуры . На рисунке 5.2 приведены базовые компоненты архитектуры согласно методологии TOGAF (The Open Group Architecture Framework). Де-факто фреймворк TOGAF стал стандартом описания архитектуры предприятия и может использоваться любой организацией, разрабатывающей собственную архитектуру.

Для удобства описания авторы раздела называют компоненты архитектуры слоями. Хотя это не полностью равнозначные понятия, с точки зрения введения в архитектурный подход разница между ними несущественна. Подробнее см. Рудь В. Слои корпоративной архитектуры / Блог «Архитектура Digital».

TOGAF (The Open Group Architecture Framework) — методология описания архитектуры ИТ и предприятия, в том числе метод ее трансформации, разработанные консорциумом Open Group. Основной акцент в методологии делается на представлении в виде компонентов всех технологий и аспектов жизнедеятельности предприятия. Подробнее см. TOGAF // The Open Group.

Термин framework можно перевести как «рамочная модель» или «каркас»; это логическая структура для классификации и организации информации о сложном явлении или системе.

Подробнее о слоях и доменах см. Рудь В. Слои корпоративной архитектуры / Блог «Архитектура Digital».

Process Classification Framework // APQC.

В ассоциации TM Forum разработан ряд стандартов и рекомендаций. См. TM Forum.

Рисунок 5.2
Базовые компоненты (слои) архитектуры в методологии TOGAF

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

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

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

• Слой «Драйверы». Может включать такие элементы, как «Импортозамещение», «Цифровизация», «Противодействие эпидемии COVID-19».
• Слой «Системы». Его образуют такие элементы, как «СRM», «ЭДО», «Exchange», «Кадры», «Склад», «Портал».
• Слой «ИТ-сервисы». В нем расположены, к примеру, «Предоставление списка неоплаченных штрафов», «Предоставление данных по адресу регистрации».
• Слой «Подразделения». Слой организационных единиц, попадающих в охват стратегии трансформации. Включает, например, профильные подразделения ОИВ и подведомственные организации.

Таким образом, слой — это архитектурный класс, а элемент — конкретный представитель или экземпляр класса. 60+ слоев для удобства объединяют в шесть доменов:

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

Рисунок 5.3
Основные домены и наиболее часто используемые слои архитектуры

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

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

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

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

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

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

• выбрать и описать один слой (например, составить реестр ИТ-систем с рядом атрибутов, таких как производитель, ответственный, количество лицензий);

• построить карту процессов, описать их и провести оптимизацию некоторых из них (например, уменьшить количество шагов согласования отпуска или командировки);

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

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

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

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

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

Таблица 5.1
Изменение слоев архитектуры при цифровой трансформации муниципальной услуги по выдаче разрешений на строительство

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

5.1.2 Архитектурные решения

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

Не следует путать управленческое решение с платформенным, описанным в разделе 6.

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

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

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

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

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

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

Классический пример из этой области — строительство дома. Будущий дом — это набор моделей:

• модель (чертежи и решения) несущих конструкций дома;
• модель (чертежи и решения) электрификации дома;
• модель (чертежи и решения) отопления дома;
• модель (чертежи и решения) водоснабжения и водоотвода дома.

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

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

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

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

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

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

5.1.3 ИТ-архитектура и ее роль в архитектуре предприятия

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

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

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

DevOps (DEVelopment OPeration) — повышение эффективности процессов разработки (Development) и эксплуатации (Operation) программного обеспечения за счет их непрерывной интеграции и активного взаимодействия профильных специалистов с помощью инструментов автоматизации. См. Вечугова А. DevOps // Школа Больших Данных.

К универсальным доменам описания «Архитектура предприятия» относятся:

Элементы архитектуры предприятия:

Правильны принципы:

Портфель прикладных систем включает в себя:

«Узким местом» ИТ-стратегии в бизнесе является:

К основным затратам на ИТ относятся:

Оптимальный для успеха проекта элементы:

Бюджет развития — это часть ИТ-бюджета:

Доменом архитектуры является:

Целью управления ИТ бизнеса является:

Ключевые ИТ-отношения в бизнесе — это:

Основные идеи адаптивной инфраструктуры:

Модель МЕТА Group имеет:

На вопрос: «С помощью каких решений можно построить решение?» отвечают на уровне архитектуры:

Уровни размещения инфраструктуры верно следуют друг за другом в варианте:

В списке требований: операционные, технологические, сетевые, архитектуре приложений соответствуют:

Бюджет эволюционных затрат — это затраты на:

Подход Питера Кина базируется на критерии:

K NASCIO не имеет прямого отношения:

Возможны функции систем разработки архитектуры предприятия:

Сервис-ориентированная архитектура опирается на:

К типичным сферам интересов SAM не относится:

Схема процесса Gар-разработки архитектуры ИТ верно перечислена в:

Наихудшим разбиением при описании архитектуры предприятия является разбиение на подсистемы в количестве:

Динамичность предприятия предполагает:

Основная причина сложности внедрения и использования ИТ:

К методике ISO близок стандарт:

Существуют принципы:

Положительные стороны проектирования «сверху — вниз»:

Аспект стандартизации включает:

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

ИТ в бизнесе не позволяет:

Наибольшее влияние на использование ИТ в бизнесе оказывает:

«Узким местом» ИТ-стратегии в бизнесе является:

«Предприятие реального времени» — это предприятие:

Хронологически правильна последовательность приоритетов бизнеса:

Бизнес-стратегия базируется на:

Основные причины использования ИТ в инновационных целях:

На ИТ-бюджет оказывают наибольшее влияние:

К Основным затратам на ИТ относятся:

Бюджет развития — это:

Использование ИТ в организации имеет составляющую:

«Удвоение плотности размещения транзисторов на кристалле происходит каждые 1,5 года» — это закон:

Стратегия процветания бизнеса ориентируется обычно на:

Любая технология в своем технологическом развитии проходит последовательно этапы:

Организация типа В (пo Gartner) – это организация:

Профиль индивидуальности организации (ЕРР) базируется на:

Когнитивная решетка Gartner состоит из осей:

Наиболее часто имеются следующие преимущества, связанные с наличием «Архитектуры предприятия»:

Системный анализ имеет все указанные в списке ветви:

Предприятие – это:

Архитектура ИТ-семейство

Архитектуры по уровню различаются

Верно утверждение:

Программная архитектура-это:

Верна формула:

Целью управления ИТ бизнеса не является:

Реинжиниринг – это:

Современный бизнес характерен всегда:

Любое архитектурное решение основывается на выборе:

Успешные методики описания Архитектуры предприятия используют обычно метод:

При описании Архитектуры предприятия важны понятия:

Верно утверждение:

К не универсальным доменам описания «Архитектура предприятия» относятся:

На проектировщиков ориентирован уровень архитектуры:

На вопрос: «Каково видение решения?» отвечают на уровне архитектуры:

На вопрос: «С помощью каких технологий можно построить решение?» отвечают на уровне архитектуры:

В большинстве случаев:

На вопрос: «Почему организация занимается таким бизнесом?» отвечает уровень:

На вопрос: «Каковы факторы, определяющие достижение высоких результатов?» отвечает уровень:

На вопрос: «Какой «фронт — офис» или «бэк — офис» будет использоваться?» отвечает уровень:

На вопрос: «Какая информация требуется для бизнес-процесса?» отвечает уровень:

Доменом архитектуры является:

Доменом архитектуры является:

Руководящие принципы относятся к:

Процедуры относятся к:

Правильные принципы:

Правильны принципы:

Примеры управления данными — обеспечение:

Правилен принцип для любой ИТ-организации:

Вопросом во фрагменте: «обработка и анализ информации →​ ? →​ выявление управляющих параметров» цикла управления предприятием помечен этап:

Если актуальные проблемы «привязывают» к возможностям технологии, то такая концепция разработки информационных систем называется:

К основным свойствам любой модели относится:

Основная область архитектуры приложений:

Область разработки прикладных систем определяет:

Портфель прикладных систем включает всегда:

Модель оценки портфеля прикладных систем может использовать критерий:

Категорией оценки прикладных систем является:

Категорией оценки прикладных систем является:

Каталог прикладных систем всегда должен включать:

Каталог прикладных систем всегда должен включать:

Каталог прикладных систем всегда должен включать:

Классификационным критерием является:

Классификационным критерием является:

Эффективность ИТ определяется соотношением:

Основное назначение технологической архитектуры — это:

Реальное преимущество наличия адекватной ИТ-инфраструктуры:

Реальное преимущество наличия адекватной ИТ-инфраструктуры:

Пример базового домена технологической архитектуры:

Пример базового домена технологической архитектуры:

Отметьте компонент или сервисы в технологической архитектуре по Gartner:

В архитектурный компонент «Сервисы безопасности» входит:

В списке: операционные, технологические, сетевые, функциональным требованиям соответствуют:

Подход Питера Кина базируется на критерии:

Основной характеристикой адаптивной системы является:

Основные идеи адаптивной инфраструктуры:

Ряд моделей: Garther, МЕТА Group, TOGAF лучше продолжить:

К требованиям описания ИТ-архитектуры не относится:

Верно «определение» архитектуры как:

Последовательность имен: данные, функции, дислокация, люди, время, мотивация, отражает в модели Захмана структуру:

Основным правилом заполнения таблицы Захмана является:

Основным правилом заполнения таблицы Захмана является заполнение клеток:

Вторая строка таблицы Захмана соответствует:

Шестая строка таблицы Захмана соответствует:

Модель Gartner 2002 имеет уровни:

По методике АДМ, процесс разработки включает фазы:

Методика NASCIO включает уровни:

Домены NASCIO:

Домены NASCIO:

В домен управления системами NASCIO входит:

K NASCIO не имеет прямого отношения:

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

Сети бывают:

Для описания конкретного решения используется шаблон:

Модель «4+1» базируется на всех представлениях:

SAM — модель архитектуры

К типичным сферам интересов SAM не относится:

Проект работы над созданием архитектуры обычно включает:

Подходу проектирования «сверху-вниз» присущи следующие положительные аспекты:

Отрицательные стороны проектирования «сверху — вниз»

Оптимальный состав МЕТА — команды:

Отрицательные стороны проектирования «снизу — вверх»:

Принципом управления и контроля архитектуры предприятия является выполнение процедуры:

Общим подходом управления и контроля архитектуры является распространение информации:

Элементом управления и контроля архитектуры на этапе анализа и проектирования является:

К организационным структурам управления и контроля архитектуры относится:

Gap-анализ включает этап:

Аспект стандартизации включает:

Начальный уровень организационной зрелости характеризует:

Главная цель проекта:

Стратегическое окно для «хорошей» архитектуры — это:

Наиболее важным при управлении архитектурой является:

Источником информации для систем разработки архитектуры является:

Возможны функции систем разработки архитектуры предприятия:

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

Приложения для выполнения, функции предприятия, обмен информацией при выполнении их описывает:

Для бизнес-стратегии необходима(ы) адекватная(ые):

Необходимо придерживаться в разработке архитектуры подхода:

Когнитивная решетка Gartner состоит из осей:

Основных категорий оценки прикладных систем всего:

Стратегия процветания бизнеса ориентируется обычно на:

Домены NASCIO:

Модель «4+1» базируется на всех представлениях:

Наиболее часто имеются следующие преимущества, связанные с наличием «Архитектуры предприятия»:

Неверно утверждение в бизнесе:

Основных затрат на ИТ – всего:

Модель Gartner 2002 имеет уровни:

Хронологически правильна последовательность приоритетов бизнес-моделирования:

Примеры управления данными — обеспечение:

Наиболее важным при управлении архитектурой является:

Каталог прикладных систем всегда должен включать:

Выберите продолжение фразы: ИТ-стратегия, в основном, стратегия

На вопрос: «Централизован (децентрализован) бизнес организации?» отвечает уровень:

Оптимальная структура описания ИТ — архитектуры:

Основная причина сложности внедрения и использования ИТ:

Пример базового домена технологической архитектуры:

Управляемый уровень организационной зрелости характеризует:

Использование ИТ в организации имеет составляющую:

Частная информация предполагает:

Примеры преимуществ от использования ИТ:

Стратегия процветания бизнеса ориентируется обычно на:

Процесс перехода от текущего к будущему портфелю прикладных систем — это:

Элементом управления и контроля архитектуры на этапе начала проекта является:

К основным свойствам любой модели относится:

Профиль индивидуальности организации (ЕРР) базируется на:

Основной характеристикой адаптивной системы является:

Основные домены описания Архитектуры предприятий:

Выберите продолжение фразы: ИТ-стратегия определяет, в основном,

Наибольшее влияние на использование ИТ в бизнесе оказывают:

ИТ-бюджет включает:

Бюджет обязательных затрат — это затраты на:

Организация типа А (пo Gartner) – это организация:

Неправильно утверждение:

Уровни принятия архитектурных решений:

Архитектура бывает двух основных типов:

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

К числу основных пользователей Архитектуры предприятия не относятся:

Уровни эволюции контекста Архитектуры предприятия:

Архитектура предприятия:

На вопрос: «Как выглядят бизнес — процессы?» отвечает уровень:

На вопрос: «Каковы общие принципы использования технологий ?» отвечает уровень:

Доменом архитектуры является:

ИТ — архитектура относятся к:

Правильно упорядочена последовательность:

Неправилен принцип: архитектура

Правилен принцип для любой ИТ-организации:

В правила организации информации для управления предприятием входит:

Если возможности технологии «привязывают» к решаемым проблемам, то такая концепция разработки информационных систем называется:

К основным свойствам любой модели относится:

Область разработки прикладных систем определяет:

Категорией оценки прикладных систем является:

Категорией оценки прикладных систем является:

Матрица оценки — это:

Классификационным критерием является:

Эффективность ИТ определяется соотношением:

Инвестиции в ИТ-инфраструктуру обычно:

Реальное преимущество наличия адекватной ИТ-инфраструктуры:

Уровни размещения инфраструктуры верно следуют друг за другом в варианте:

Архитектурный компонент (сервис):

Архитектурный компонент (сервис):

Основной характеристикой адаптивной системы является:

Основные идеи адаптивной инфраструктуры:

К методике (стандарту) IEEE близок стандарт:

Последовательность имен: планировщик, менеджер, архитектор, проектировщик, разработчик отражает в модели Захмана структуру:

Основным правилом заполнения таблицы Захмана является:

Первая строка таблицы Захмана соответствует:

Пятая строка таблицы Захмана соответствует:

Модель Gartner 2002 имеет уровни:

Методика NASCIO включает уровни:

Домены NASCIO:

В домен управления системами NASCIO входит:

K NASCIO не имеет прямого отношения:

По доступу список дисциплин: Web-дизаин, Доступность, Доступ лучше продолжить:

Для описания конкретного решения используется шаблон:

SAM использует

Проект работы над созданием архитектуры обычно включает:

Наиболее возможные подходы организации процесса разработки архитектуры:

Отрицательные стороны проектирования «сверху — вниз»:

В результате реализации схемы: мониторинг, анализ, спецификация, стандарты, аудит, план миграции, реализация получим:

Общим подходом управления и контроля архитектуры является контроль процесса:

К организационным структурам управления и контроля архитектуры относится:

Gap-анализ включает этап:

Аспект стандартизации включает:

Необходимо при проектировании архитектуры рассматривать промежутки времени:

Перспективных возможностей окно для «хорошей» архитектуры — это:

Наиболее важным при управлении архитектурой является:

Источником информации для систем разработки архитектуры является:

Возможны функции систем разработки архитектуры предприятия:

Отрицательные стороны проектирования «сверху — вниз»:

К организационным структурам управления и контроля архитектуры относится:

Сервис-ориентированная архитектура опирается, в первую очередь, на:

На вопрос: «Как могут быть удовлетворены требования?» отвечают на уровне архитектуры:

Архитектурный процесс верно указан в:

Элементом управления и контроля архитектуры на этапе выработки требований является:

Принципом управления и контроля архитектуры предприятия является выполнение процедуры:

Организация типа С (пo Gartner) – это организация:

Цели, приоритеты в управлении информационной системой определяются:

Основная область архитектуры приложений:

Полезность архитектурного решения может определяться:

Домены NASCIO:

Ценность архитектуры предприятия состоит, в основном:

«Предприятие реального времени» — это предприятие:

В технологическом развитии любой ИТ есть этапы:

Существуют принципы:

ИТ в бизнесе позволяют:

Динамичность предприятия – это способность:

«Узким местом» ИТ-стратегии в бизнесе является:

Хронологически правильна последовательность приоритетов принятия решения в бизнесе:

Какие отношения для бизнес-стратегии являются основными?

Ключевые ИТ-процессы в бизнесе:

На ИТ-бюджет оказывают наибольшее влияние:

«Ценность сетевой структуры экспоненциально возрастает с ростом числа подключений к сети» — это закон:

Профиль индивидуальности организации (ЕРР) базируется на:

Наиболее часто имеются следующие преимущества, связанные с наличием «Архитектуры предприятия»:

Системное мышление – это методология:

Архитектура ИТ зависит от:

Эволюция представления «Архитектура предприятия»:

Ключевой концепцией Архитектуры предприятия является концепция:

Современный бизнес характерен всегда:

Основные пользователями Архитектуры предприятия:

Уровни абстракции Архитектуры:

Верно утверждение:

На «владельцев» бизнес — процессов ориентирован уровень архитектуры:

На вопрос: «Каковы общие требования?» отвечают на уровне архитектуры:

На вопрос: «Каких целей добивается организация?» отвечает уровень:

На вопрос: «Каковы индустриальные ценности?» отвечает уровень:

Доменом архитектуры может быть архитектура:

Цели, задачи относятся к:

Руководства относятся к:

Правилен принцип: архитектура

Примеры управления данными — обеспечение:

Каталог прикладных систем всегда должен включать:

Каталог прикладных систем всегда должен включать:

Инвестиции в ИТ-инфраструктуре обычно:

Реальное преимущество наличия адекватной ИТ-инфраструктуры:

Архитектурный компонент (сервис):

Ряд моделей: Garther, МЕТА Group, TOGAF лучше продолжить:

К требованиям описания ИТ-архитектуры не относится:

Верно «определение» архитектуры как:

Модель МЕТА GROUP имеет этапы:

Методология TOGAF опирается на элементы структуры:

В домен управления системами NASCIO входит:

В домен управления системами NASCIO входит:

K NASCIO не имеет прямого отношения:

Безопасность бывает:

Для описания конкретного решения используется шаблон:

Проект работы над созданием архитектуры обычно включает:

Gap-анализ включает этап:

Повторяемый уровень организационной зрелости характеризует:

Тактическое окно для «хорошей» архитектуры — это:

Вопросом во фрагменте: «выявление управляющих параметров →​ ? →​ управление траекторией системы» цикла управления предприятием помечен этап:

Существующих основных классов приложений прикладных систем всего:

Примеры преимуществ от использования ИТ:

Архитектурный компонент (сервис):

Основным правилом заполнения таблицы Захмана является:

Наибольшее влияние на использование ИТ в бизнесе оказывает:

«Предприятие реального времени» — это предприятие:

«Рост пропускной способности ИТ-сетей как минимум в 3 раза превышает мощность компьютеров» — это закон:

Системный анализ – это:

Архитектура ИТ бывает у:

Современная архитектура предприятия всегда:

Доменом архитектуры является:

ИТ — стандарты относятся к:

Правилен принцип для любой ИТ-организации:

Каталог прикладных систем всегда должен включать:

Пример базового домена технологической архитектуры:

Основной характеристикой адаптивной системы является:

К методике The Open Group близок стандарт:

Верно «определение» архитектуры как:

Основным правилом заполнения таблицы Захмана является независимость:

Положительные стороны проектирования «сверху — вниз»:

К не универсальным доменам описания «Архитектура предприятия» относятся:

Основным правилом заполнения таблицы Захмана является:

В списке требований: операционные, технологические, сетевые, правилам развертывания приложений соответствуют:

Каталог прикладных систем всегда должен включать:

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

Пример базового домена технологической архитектуры:

На вопрос: «С помощью каких технологий можно построить решение?» отвечают на уровне архитектуры:

Существуют принципы:

Модель оценки портфеля прикладных систем может использовать критерий:

Категорией оценки прикладных систем является:

Модель МЕТА GROUP имеет:

К типичным сферам интересов SAM не относится:

Принципом управления и контроля архитектуры предприятия является выполнение процедуры:

Технология META Group выделяет различного типа доменов технологической архитектуры:

Положительные стороны проектирования «снизу — вверх»:

Общим подходом управления и контроля архитектуры является создание (выбор):

Наилучшим разбиением при описании архитектуры предприятия является разбиение на подсистемы в количестве:

Четвертая строка таблицы Захмана соответствует:

На бизнес-руководство ориентирован уровень архитектуры:

SAM использует нотацию:

Источником информации для систем разработки архитектуры является:

Применение ИТ бизнеса опирается на:

Динамичность предприятия всегда предполагает:

Системное проектирование — это:

На ИТ-бюджет оказывают наибольшее влияние:

Архитектура ИТ определяется всегда:

Портфель прикладных систем — это интегрированный набор:

Ряд моделей: Garther, МЕТА Group, TOGAF, лучше продолжить:

По методике АДМ, процесс разработки включает фазы:

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

Эффективность решения определяется, в основном,

Третья строка таблицы Захмана соответствует:

Методика NASCIO включает уровни:

В технологическом развитии любой ИТ нет этапа:

Когнитивная решетка Gartner состоит из осей:

Правильно утверждение:

Примеры преимуществ от использования ИТ:

Модель Захмана — это таблица:

В домен управления системами NASCIO входит:

На вопрос: «Каковы функции бизнеса?» отвечает уровень:

В составе списка доменов NASCIO входят:

К требованиям описания ИТ-архитектуры не относится:

Область разработки прикладных систем определяет:

Александр КВАРЦХАВА

Проблемы управления бизнес-архитектурой компании

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

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

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

• Что такое бизнес-архитектура, и кто отвечает за её проектирование
• Какие типовые мифы существуют о бизнес-архитектуре
• С какими проблемами сталкиваются бизнес-архитекторы в работе
• Какие фундаментальные решения должны быть приняты в компаниях для управления бизнес-архитектурой
• О наиболее часто используемых методологиях (TOGAF и ArchiMate) для проектирования бизнес-архитектуры
• Как выглядит на практике построение бизнес-архитектуры

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

Что такое бизнес-архитектура?

Бизнес-архитектура (далее БА) — это совокупность социальных групп, их взаимодействий, правил этих взаимодействий и фундаментальных принципов организации групп и взаимодействий.

TOGAF — методология управления БА

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

• участие каждого из приложений в бизнес-процессах компании
• взаимодействие приложений друг с другом и внешними сервисами

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

Эта часть фреймворка TOGAF условно называется статической.

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

На предварительной фазе цикла определяются фундаментальные вопросы: нужен ли TOGAF и в каком объёме, кто будет принимать решения. К моменту запуска полноценного архитектурного цикла обязательно должны быть описаны и формализованы текущее состояние БА и ИТ-архитектуры.

На стадии A. Архитектурного видения создаётся дорожная карта неудовлетворённостей: что не нравится, почему не нравится, что планируется с этим делать, какими средствами планируется это делать, какие есть ограничения.

Далее, на стадиях B. Архитектура бизнеса, С. Архитектуры информационных систем, D. Архитектура технологии происходит проектирование целевого состояния для реализации архитектурного видения.

На фазах E. Возможности и решения и F. Планирование миграции определяется набор возможных средств для достижения целевой архитектуры и мероприятия для перехода из текущего состояния архитектуры в целевое.

Фазы G. Управление реализацией и H. Управление изменением архитектуры отвечают за исполнение. В конце цикла проводится аудит результатов и запускается новый цикл.

ArchiMate — язык описания бизнес-процессов

Для моделирования бизнес-архитектуры дополнительно имеет смысл использовать язык ArchiMate. Он был разработан в The Open Group, создавшей стандарт архитектуры предприятия TOGAF.

Язык ArchiMate дополняет методику и инструментарий TOGAF визуальным языком описания архитектуры, как внутри, так и между бизнес-областями. Уровни описания архитектуры в ArchiMate соответствуют разделению, принятому в TOGAF, поэтому их совместное использование позволяет комплексно описать архитектуру предприятия.

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

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

На рисунке ниже представлена модель этого процесса в TOGAF, реализованная языком ArchiMate.

• ФИО сотрудника — это конкретный человек, являющийся инициатором запуска бизнес-процесса;
• Менеджер по закупкам — роль, которую выполняет сотрудник;
• Логистика — функция, за которую отвечает сотрудник;
• Стратегическая закупка — процесс, находящийся внутри функции и являющийся его неотъемлемой частью;
• Контракт с оптимальными параметрами (напр. по минимальной цене и с максимальной отсрочкой платежей) — сервис, представляющий из себя ключевую ценность бизнес-процесса.
• Запуск процесса в Битрикс24 — интерфейс для доступа к сервису другими сотрудникам компании.

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

Связь бизнес-архитектуры с другими частями корпоративной архитектуры

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

За каждым «сервисом на уровне бизнеса» стоит «сервис на уровне системой архитектуры». А за каждым «сервисом системной архитектуры» — «сервис уровня технологической архитектуры».

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

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

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

Мифы о бизнес-архитектуре

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

Типовые проблемы, с которыми сталкивается бизнес-архитектор

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

Фундамент решений, которые необходимо принять для проектирования БА

Как только руководство компании принимает решение о необходимости проектирования БА и найме для этого соответствующих сотрудников, оно должно быть готово предпринять следующие действия:

1. Создать роль бизнес-архитектора в компании.
Стоит учесть, что бизнес-аналитик и бизнес-архитектор это две разные роли, имеющие разные обязанности. Бизнес-аналитик — это помощник бизнес-архитектора. Его задачи: проводить интервью, документировать, создавать концепты, перенимать опыт бизнес-архитектора. Бизнес-архитектор — аналитик, проектировщик и контролёр реализации.

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

3. Формализовать сервисы и интерфейсы между службами и подразделениями
Требуется чётко сформулировать: кто, что, кому, когда и в каком объёме должен предоставлять и получать.

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

5. Централизованно управлять не только БА, но и ИТ-архитектурой компании.
И тем, и другим надо управлять в единстве.

Этапы проектирования бизнес-архитектуры

1. ФТ: процесс должен обеспечивать передачу материалов со склада в производство.
2. НФТ: один экземпляр процесса должен осуществляться не дольше, чем 30 мин.
3. Ограничение: процесс должен выполняться силами не более, чем 3 сотрудников.

Далее, стоит составить подробное описание текущего состояния бизнес-архитектуры. Нужно подумать о том, какие существуют процессы рядом с нашим, проектируемым? С какими из них нужно будет взаимодействовать и как? Какие будут использованы интерфейсы доступа к сервису, который наш процесс создаёт? И один из важнейших вопросов: какой будет ценность, создаваемая бизнес-процессом?

И только затем, исходя из собранных требований, описанного текущего состояния и формализованных целей — вот после всего этого имеет смысл переходить к реализации прототипа. Здесь, как и в разработке, начинать надо с MVP (Minimal Viable Product — минимально жизнеспособный продукт). Делаем прототип бизнес-процесса, проводим тестирование, собираем обратную связь и развиваем прототип процесса, совершенствуя тот сервис, над которым работаем. Очень важно придерживаться этих шагов.

Например, на первой фазе процесса «Передача материалов со склада в производство», в стадии MVP, мы можем спроектировать процесс так: сотрудники относят материалы в производство на руках. Затем, наблюдая за ситуацией, мы видим, что объём материалов растёт и процесс замедляется, необходимо внести коррективы.

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

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

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

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

• Вопрос:

  Где можно применять TOGAF в реальной практике?
  

  Ответ:

  TOGAF может быть применён в любой организации, как коммерческой, так и некоммерческой. Другое дело, что до его использования компания должна «дорасти».

• Вопрос:

  Что должен знать и понимать о бизнес-архитектуре системный аналитик, product owner?

  Ответ:

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

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

• Вопрос:

  Чем БА отличается от ИТ-архитектуры?

  Ответ:

  БА — это совокупность социальных компонентов, и она содержит в себе неотъемлемый компонент — иррациональные взаимодействия, за который отвечает HR. ИТ-архитектура — это техническая составляющая, и если всё формализовано, то работать она будет именно так, как её формализовали. В БА, если не поставлена работа с иррациональным взаимодействиями, то работать она будет непредсказуемо, невзирая на формализацию.

• Вопрос:

  Что первично, БА или ИТ-архитектура?

  Ответ:

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

Александр Кварцхава

Директор по управлению IT и корпоративной архитектурой