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

Архитектура системы и Бизнес-архитектура

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

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

Архитектура и строительные конструкции

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

Строительный проект состоит из двух основных частей: архитектурно-строительной и инженерной.

Архитектурно-строительная часть проекта включает:

… место для размышлений …

Архитектура системы

Теперь рассмотрим определение, которые ближе к IT. За основу возьму выдержки из статьи.

Архитектура – фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции. (Из: ISO/IEC/IEEE 42010:2011)

Архитектура – это проектные решения, которые тяжело изменить. (Мартин Фаулер)

Однако, существует тонкость с характеристикой «тяжело изменить».

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

Нет никакой теоретической причины, что что-то трудно изменить в отношении программного обеспечения. Если вы выбираете какой-либо один аспект программного обеспечения, вы можете легко изменить его, но мы не знаем, как сделать всё легко изменяемым. Сделать что-то легким для изменения — делает общую систему немного сложнее, а сделать всё легким для изменения — делает всю систему очень сложной. (Ральф Джонсон)

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

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

Проблема

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

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

… место для размышлений …

Большая часть системных архитекторов вышло из программистов, они все технократы. Это всё придумали они. 🙂
При работе с архитектурой лучше сфокусироваться на назначение Системы.

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

Это проектное решение, которое колеса, двигатель, корпус и рулевое управление организует в автомобиль.

Другими словами, Архитектура – это проектное решение, которое дает эффект эмерджентности. Эмерджентность — появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
Важно не смешивать уровни абстракции. Также позже, может возникнуть вопрос, что такое хорошая архитектура? Архитектура должная обеспечивать реализацию трех основные атрибутов качества системы: надежность, эффективность, гибкость. Есть и другие, например, масштабируемость, тестируемость, ремонтопригодность и др., но они не всегда так важны.

Бизнес-архитектура

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

Для описания основы бизнес-архитектуры, как любой другой архитектуры, используются три аспекта:

Концепция «Три вида деятельности»

Существуют три вида деятельности:

Концепция «Циклы Деминга»

Итак, мы как архитекторы разделили деятельность компании на три части. Теперь нужно понять, а как же это все вместе работает. Для этого нам потребуется еще одна старая, но по-прежнему актуальная концепция – цикл Деминга, он же PDCA:

Посмотрим нашу конкретную проектную работу, производство продукта или оказание услуги:

Концепция «Принятие решения»

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

Давайте сопоставим эту концепцию с нашими проектами:

Принцип «Целевое назначение должно определять архитектуру»

Тут важно напомнить определение архитектуры:

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

Целевым назначением обычно является основная деятельность. Управляющая деятельность направлена на основную деятельность. Поддерживающая деятельность обеспечивает ее.

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

Принцип «Архитектура должна соответствовать руководству»

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

Возможен внутренний конфликт.

… место для размышлений …

Определение Бизнес-архитектуры

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

Из существующих определений мне нравится, которое дала группа Architecture Board Special Interest Group (BASIG) (Специальный совет по архитектуре OMG)

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

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

Архитектор

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

Задача сапожника изготавливать и ремонтировать обувь.

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

Какими компетенциями он должен обладать?

Архитектор должен знать архитектурные принципы и концепции на своем уровне бизнеса или системы, это его hardskills.

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

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

Источник

Что описывает корпоративная архитектура

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

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

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

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

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

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

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

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

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

• Процесс контроля заявления по форме (полнота представленных данных) переходит от сотрудников к форматно-логическому контролю.

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

• Для пользователей цифрового сервиса запущен чат-бот, поддержка и актуализация базы знаний внесена в число функций подразделения, ранее занятого ручной обработкой заявлений на получение разрешения на строительство. Логические данные;Полностью пересматривается логическая структура данных под потребности работы алгоритмов. Создаются ведомственные дата-сеты. они становятся, по сути дела, библиотеками, которые остальные министерства и ведомства могут использовать как конструктор. Компоненты, функции, доступ к реестрам можно масштабировать не только на уровне министерств, но и в субъекты Федерации. Технологическая ИТ-архитектура: ЦОДы;Рассчитываются инфраструктурные мощности, необходимые для функционирования сервиса предоставления разрешений с целевыми параметрами:

• доступность (24/7) по всем необходимым средствам всем заинтересованным сторонам.

• мощность (способность обслужить поток заявлений конкретного муниципального образования).

• непрерывность (возможность продолжения предоставления сервиса в ситуации сбоев и высоких нагрузок). Интеграции;Запрос информации из смежных ОИВ осуществляется через API.

Источник

Что такое архитектура предприятия и как ее проектировать: TOGAF vs ARIS

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

Продолжая речь про анализ корпоративной деятельности, сегодня рассмотрим основы архитектуры предприятия и разберем 2 наиболее популярных подхода к ее проектированию: TOGAF и ARIS. Читайте далее, какие еще архитектурные фреймворки выделяет руководство по бизнес-анализу BABOK®Guide, чем TOGAF отличается от ARIS и как этот подход позволяет бизнес-аналитику комплексно описать корпоративную деятельность.

Немного об архитектуре предприятия: взгляд BABOK и не только

Описание корпоративной деятельности с целью ее оптимизации не сводится только к моделированию бизнес-процессов в стандартных нотациях, которые мы разбирали здесь. Согласно рекомендациям BABOK®Guide в главе «Анализ стратегии» (Strategy Analysis), следует также проанализировать существующие на предприятии организационные структуры (проектные и функциональные), цели и показатели их достижения, линейку создаваемых продуктов/услуг, которые приносят доход, а также инфраструктуру (программное и аппаратное обеспечение, оборудование), используемые в работе. Все это в совокупности образует единую систему – архитектуру предприятия, для проектирования которой существует множество специальных подходов (фреймворков), наиболее популярным из которых сегодня считается TOGAF (The Open Group Architecture Framework).

Справедливости ради стоит отметить, что руководство по бизнес-анализу BABOK®Guide при описании перспективы «Бизнес-архитектура» упоминает не только TOGAF, но и другие архитектурные фреймворки, например, eTOM, COBIT, ITIL, PCF и пр. в качестве эталонных бизнес-моделей, универсальных или специфических для отдельных предметных областей. При этом в BABOK фреймворк TOGAF позиционируется в качестве метода (техники), будучи упомянутым вместе с такими подходами как CJM, дорожная карта, фреймворк Захмана и т.д. Однако, такое позиционирование вызывает вопросы, поскольку TOGAF и, к примеру, карта взаимодействия с клиентом (Customer Journey Map, CJM) имеют абсолютно разные объемы и точки описания корпоративной деятельности. Впрочем, этот вопрос снимается, если вспомнить, что BABOK – это не строгий ГОСТ, а сборник лучших практик бизнес-анализа, не претендующий на абсолютную полноту содержащихся в нем знаний и рекомендаций.

Штурм BABOK за 5 дней: подготовка бизнес-аналитиков к экзамену на сертификат CBAP/CCBA (IIBA® Endorsed Сourse, 40 PD)

Код курса
Ближайшая дата курса
Длительность обучения
40 ак.часов
Стоимость обучения
75 000 руб.

TOGAF vs ARIS: основы моделирования корпоративной архитектуры

Возвращаясь к TOGAF, поясним, что этот высокоуровневый подход, разработанный в 1991 на основе фреймворка Министерства обороны США TAFIM, предлагает описывать архитектуру предприятия в разрезе следующих основных доменов [1]:

Если сравнивать этот архитектурный фреймворк с методологией бизнес-моделирования ARIS, реализованной в одноименном программном продукте немецкой компании IDS Scheer (ныне часть Software AG), TOGAF позволяет описать корпоративную деятельность более полно, поскольку включает также и аппаратную часть (домен «Технологии»). ARIS же рассматривает предприятие с пяти точек зрения [2]:

Каждая из этих точек зрения детализируется на описание требований, спецификации и особенностей реализации (внедрения).

что описывает корпоративная архитектура«Здание ARIS» — основные точки зрения для описания архитектуры предприятия

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

Источник

Методы архитектуры предприятия

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

В рамках урока поговорили:

об обоснованных структурных изменениях в компании в быстро меняющихся условиях;

о применении архитектурного подхода в вопросах трансформации;

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

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

Зачем нужна цифровая трансформация?

Понятно, что цифровая трансформация в различных индустриях продиктована разными причинами и по-разному воплощается.

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

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

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

Почему это происходит?

Имеют место два фактора:

Меняются клиенты, меняется рынок. Рынок становится более быстрым. Клиенты становятся более разборчивыми и требовательными.

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

И в совокупности эти факторы требуют совершенно другого от бизнеса.

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

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

Что такое цифровая трансформация, как ее измерить?

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

1. Неисчерпаемый перечень.

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

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

2. Скорость внедрения изменений

Гибкость продукта, услуг. (насколько мы гибкие в изменениях параметров, в настройках продукта, который мы доставляем клиенту).

Гибкость платформы (насколько платформа поддерживает Devops, Agile Development, гибкое выделение инфраструктуры).

3. Данные dеitadreavon

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

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

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

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

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

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

6. Быть актуальными

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

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

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

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

Поговорив о сути и направлении цифровой трансформации, следует рассказать о том, как и где принимаются решения?

с одной стороны, достаточно структурированной и системной;

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

также важна коммуникация.

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

Таким образом, если ты хочешь внести улучшение в компании:

ты знаешь, как эту идею структурировать.

Хорошо представить идею;

Понимать, каким образом компания примет решение о том, что эта идея будет запущена или не будет.

Как устроено принятие решения об изменениях в организации.

Любое изменение – это выделение бюджета.
Любое выделение бюджета – это инвестиции.

Бюджет может выделяться:

Напрямую, комитетом, в виде какой-то суммы;

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

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

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

Процесс, формирующий общий портфель изменений

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

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

Инвестиционная стратегия. Склонность к риску. Насколько мы готовы экспериментировать. Насколько консервативны при отборе решений, в которые мы вкладываем деньги.

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

Исполнение портфеля. Управление результативностью портфеля. Качество проектной деятельности. Метрики, попадание в сроки.

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

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

Заглядываем и видим портфель изменений.

Смотрим на результативность портфеля с точки зрения обратной связи. (сдвигаются /не сдвигаются сроки, что меняется).

Участвуем в инвестиционном процессе.

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

The Open Agile Architecture – новый стандарт. Как заниматься архитектурой в agile среде.

Почему именно ADM (Architecture Development Method)?

Стандарт Тogaf, достаточно громоздкий. Мало кто им пользовался, как методическими указаниями. Однако, помимо того, что он содержит ряд здравых базовых мыслей, связанных с декомпозицией, в нем есть жизненный цикл архитектуры предприятия, цикл разработки архитектуры. Если мы пойдем в agile без понимания этой логической последовательности действий, то можем потерять саму архитектуру.

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

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

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

A. Видение архитектуры. Исходя из того куда движется компания, понимание того, где мы находимся и куда мы хотим прийти, какой наша организация должна стать.
B. Бизнес-архитектура. Более структурированный анализ. Как должен быть устроен наш бизнес. Как должна эволюционировать наша бизнес-модель, и операционной модель.
C. Архитектура информационных систем.
D. Техническая архитектура.
Как это реализуется технологически.
E. Возможности и решения. Какие технические решения нам нужны, чтобы реализовать функции в тех приложениях, которые мы у себя заложили, или которые решили развивать.
F. Планирование миграции. Планируем переход из состояния А, в состояние Б.
G. Управление реализацией. Как некая дорожная карта изменений компании последовательно/параллельно. Важно следить за отклонениями реализации от видения, архитектуры движения, которые мы нарисовали ранее.
H. Управление изменениями архитектуры. Любое событие, которое возникает в реальном мире, может повлиять на наше понимание организации, понимание того, куда эта организация должна двигаться.

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

Последовательность действий

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

Анализ бизнес-архитектуры

Первый шаг – это разработка бизнес-архитектуры в какой-то области. Бизнес-архитектура – это не только ландшафт бизнес-процесса.

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

Гильдия бизнес-архитектуры на базовом уровне показывает бизнес-архитектуру, как 2 концентрических круга.

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

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

    Value Streams – потоки ценности. Фундаментальные вещи, о том как организация доставляет ценность? Как организация работает? В чем ее бизнес состоит?

    Information – то как элементы бизнес-архитектуры связаны с архитектурой информационной.

    Organization – привязка всего к организационной структуре.

    Vision, strategy, and tactics – мотивация компании. Видение стратегии, куда компания движется.

    Stakeholder – лица, принимающие решения.

    Policies, Rules, Regulations – политики.

    Products & Services – продукты и услуги, то есть то, что на витрине перед клиентом.

    Initiatives & Projects – инициативы и проекты, то есть объекты изменений.

    Metrics & Measures – показатели. То, как мы это мерим.

    Начать лучше всего с capability (компетенции).
    Под компетенциями понимается совокупность:

    методологий и подходов;

    Компетенция – это возможность организации делать что-то.

    ПРИМЕР:

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

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

    Здесь мы видим, что на одной картинке объединены четыре сущности.

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

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

    Для того чтобы реализовать этот процесс, нужно:

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

    должна быть реализована настройка;

    должно быть моделирование;

    анализ хода компаний;

    обработка коммуникации в каналах коммуникаций.

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

    Здесь задействовано достаточно много систем.
    Одновременно и поток ценностей, и процессный взгляд, и компетенции компании и приложение.

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

    Информационная архитектура

    Для чего она нужна?

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

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

    На этом уровне, пока мы не выделяем контексты, пока мы описали всю информацию, важно понимать:

    какие объекты есть;

    кто за них отвечает;

    как эти объекты появляются и потребляются в рамках потока ценностей.

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

    Что мы видим на рисунке?

    Контекст продаж:

    Источник

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *