Архитектор предприятия кто это

НАЦИОНАЛЬНАЯ АССОЦИАЦИЯ АРХИТЕКТОРОВ ПРЕДПРИЯТИЯ. Контакты

> Главная
> О нас
- > Манифест
- > Устав
- > Органы управления
- > Лица ассоциации
- > Участие
- > Поддержать ассоциацию
- > Контакты
- > Об архитектуре предприятия
- > База знаний
- > Стандарт профессии
- > Партнерство
- > Блоги
Пара слов об архитектуре предприятия, людях, ею занимающихся, и директорах, ею пользующихся

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

«Кому нужна архитектура предприятия? Сколько лет предприятия жили без этой дисциплины, производили продукцию, и все было дешевле, а сейчас бездельники придумали для себя новые названия «Консультант», «Методолог», «Архитектор предприятия», а толку нет, все дорожает и становится хуже по качеству» — подобную точку зрения часто можно услышать не только от продавца на рынке, но и от директора или владельца бизнеса. Короткий ответ на это соображение таков: Мир меняется, и у нас есть инструменты, помогающие руководителям бизнеса меняться вместе с ним, быстрее его, и меняться управляемо. Подробный ответ вы найдете на нашем сайте, а также на наших бесплатных семинарах (хеш-тег #seminar_arch)

Мы публикуем интервью, заметки, статьи и размышления действующих Архитекторов Предприятий, как бы не звучало официальное название их должности, предназначенные как для специалистов (эти материалы помечены хеш-тегом #prof_arch), так и для всех интересующихся (под хеш-тегом #info_arch)

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

Архитектура предприятия, TOGAF 10 и адаптивность организационной структуры

Архитектура предприятия предназначена для самого предприятия, а не для архитекторов.

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

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

Архитектура предприятия (Enterprise Architecture, EA) разрабатывается по одной очень простой причине: чтобы служить ориентиром для эффективных изменений.

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

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

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

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

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

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

Что такое TOGAF (The Open Group Architecture Framework): Фреймворк архитектуры The Open Group?

Стандарт TOGAF — это фреймворк для определения и реализации изменений.
- Определение и описание стандартного цикла изменений, используемого для планирования, разработки, внедрения, управления, изменения и поддержания архитектуры предприятия: метод разработки архитектуры TOGAF (TOGAF Architecture Development Method, ADM).
- Определение и описание основных элементов (строительных блоков) в предприятии, используемых для предоставления бизнес-сервисов и информационных систем: фреймворк контента TOGAF (TOGAF Content Framework).
- Набор рекомендаций, методик и советов по созданию и поддержанию эффективной архитектуры предприятия и проведению изменений с помощью новых архитектур решений на всех уровнях масштаба, развития и детализации.
В качестве составляющих общей архитектуры предприятия принято выделять четыре архитектурных домена:
- Бизнес-архитектура (Business Architecture) определяет стратегию бизнеса, управление, организацию и ключевые бизнес-процессы.
- Архитектура данных (Data Architecture) представляет структуру информационных ресурсов организации, включая логическую и физическую организацию данных, а также средства управления информацией.
- Архитектура приложений (Application Architecture) предоставляет план развертывания отдельных приложений, их взаимодействия и взаимосвязи с основными бизнес-процессами организации.
- Технологическая архитектура (Technology Architecture) описывает цифровую архитектуру, логические возможности, стандарты программной и аппаратной инфраструктуры, необходимые в качестве поддержки развертывания сервисов для бизнеса, данных и приложений. Сюда входят цифровые сервисы, интернет вещей (IoT), инфраструктура социальных сетей, облачные сервисы, ИТ-инфраструктура, промежуточное ПО, сети, коммуникации, обработка данных, стандарты и т.д.
Структура документации TOGAF 10

Структура документа стандарта TOGAF — модульная и постоянно развивающаяся. В ней прослеживается четкая иерархия — от общих концепций в фундаментальном контенте TOGAF (Fundamental Content) до стабильной передовой практики в руководствах серии TOGAF (Series Guides) и новых идей в библиотеке TOGAF.
1. Фундаментальный контент стандарта TOGAF предоставляет важную «опорную структуру». Это обеспечивает стабильные и долговечные стандарты и методологии, которые могут служить основой для правильных практик и подходов к архитектуре предприятия.
2. Руководства серии (домена) (Series (Domain) guides) строятся на общем содержании, предоставленном в фундаментальном контенте TOGAF, предлагая рекомендации по конкретным темам.
3. В дополнение к стандарту TOGAF имеется обширный набор руководств и справочных материалов, известный как библиотека TOGAF, которая осуществляет поддержку по практическому применению подхода TOGAF. В этой библиотеке на данный момент доступны документы справочные модели (Reference Models) и методические рекомендации (Method Guidance), общая практическая информация (General How-To-Information)и руководство по созданию команды архитектуры предприятия (Establishing an EA Team).
Существует множество других доменов, которые могут быть определены путем объединения соответствующих представлений об областях бизнеса, данных, приложений и технологий. Например, архитектура информационных ресурсов, архитектура рисков и безопасности, архитектура цифровых решений.

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

Основой фреймворка TOGAF является метод разработки архитектуры TOGAF (TOGAF ADM).

По своей сути стандарт TOGAF обеспечивает поддержку деятельности архитекторов — их способности понимать, определять и контролировать.

Понимание

Этап A — Архитектурное видение: понимание проблемы/возможности, эскиз решения и определение общей стратегии перехода к изменениям.

Этапы B-D — Архитектура бизнеса/информационных систем/технологическая: решить, что необходимо (строительные блоки архитектуры. Architecture Building Blocks (ABB)).

На этих этапах рекомендуется выбрать потенциальные варианты для реализации решения (строительные блоки решения (Solution Building Blocks, SBB)).

Определение

Этап E — Возможности и решения: осуществить выбор из предложенного набора строительных блоков решений (SBB), оптимальных для строительных блоков архитектуры (ABB) на этапах B-D, и определить, как они будут взаимодействовать для обеспечения требуемого уровня бизнес-услуг. Установить наиболее подходящие переходные этапы реализации.

Этап F — Планирование миграции: организация ресурсов для поэтапной реализации контролируемых переходов.

Управление

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

Этап H — Управление изменениями в архитектуре: обеспечение правильного планирования, структурирования и получения ожидаемой ценности для бизнеса.

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

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

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

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

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

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

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

Важно отметить, что TOGAF ADM «не делает»:
1. Предписывает, что шаги должны выполняться в указанной последовательности.
2. Устанавливает «водопадную» (waterfall) методологию, где требуется, чтобы каждая стадия была завершена перед началом следующей.
3. Определяет продолжительность любого этапа или цикла разработки архитектуры.
Фреймворк TOGAF «делает»: рекомендует адаптировать ADM к потребностям предприятия; гибкость является одной из таких потребностей.

В рамках TOGAF представлена модель, определяющая три уровня детализации, которые могут быть использованы в целях разделения процесса разработки архитектуры:
- Стратегическая архитектура предприятия (Enterprise Strategic Architecture) предоставляет общую картину той области деятельности предприятия, которую затрагивают изменения. Она позволяет понять общее стратегическое направление развития предприятия на высоком уровне с достаточной степенью охвата, чтобы определить контекст, в который вписываются все компоненты и возможный потенциал. Это необходимо для планирования и проектирования всей работы, а также для того, чтобы избежать нежелательных последствий.
- Средний уровень — архитектуры сегментов (Segment Architectures) — обычно задает направление на уровне корпоративного портфеля, программы или продукта. Эти крупномасштабные сегменты часто соответствуют естественным границам функциональности.
- Нижний уровень — архитектуры возможностей (Capability Architectures) — представляет собой детальное описание (инкрементов) бизнес-возможностей. Они могут быть привязаны к спринтам поставки, или потребуется несколько спринтов для реализации возможностей. Такие описания достаточно подробны, чтобы их можно было передавать разработчикам для проведения необходимых действий или мероприятий. Спринты могут проводиться на любом уровне, но чаще всего они связаны с предоставлением возможностей или их увеличением.
Уровни и этапы ADM, сопоставленные с концепциями Agile

Стратегическая архитектура

На Agile-предприятии стратегическая архитектура (Strategic Architecture) является высокоуровневой итерацией, опирающейся на этап A, Архитектурное видение (Architecture Vision) TOGAF ADM. В данной итерации формулируется стратегическое направление для предприятия, которое служит основой для принятия решений. Это направление может быть дополнительно развито на этапе B, чтобы предоставить высокоуровневый обзор организационной структуры.

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

Архитектура сегмента

Архитектура сегмента (Segment Architecture) — это, как правило, спецификация продукта или бизнес-решения. Она должна быть достаточной для определения характеристик, функциональных и нефункциональных требований. Если информации, полученной в результате выполнения этапов A и B, недостаточно для выполнения этой задачи, то можно уделить больше внимания детальному изучению этапов B, C и D.

Ключевыми преимуществами сегментной архитектуры для Agile-предприятия являются:
- Поддержка для определения бэклогов на уровне возможностей
- Определение возможностей/вспомогательных средств, а затем фич и функционала, необходимых для предоставления продукта/услуги/решения.
- Определение ключевых показателей эффективности (KPI), требуемых для обеспечения доставки ценности в соответствии с обозначенным видением и бизнес-целями.
- Сегмент состоит из одного или нескольких продуктов и SBB. Необходимо предоставить лишь ту необходимую часть архитектуры, чтобы улучшить дизайн, производительность и удобство использования решения, а также обеспечить руководство для межкомандного проектирования и реализации.
- Спецификация на этом уровне должна быть ориентирована для группировки объектов на уровне портфеля при поддержке Agile-концепций, включающих эпики, параллельное проектирование, планирование непрерывной доставки и интеграции целевого решения.
Архитектура сегмента помогает сформировать продукты и решения для каждого сегмента. В результате итераций сегмента формируются элементы бэклога, на основе которых Agile-команды могут работать над реализацией продуктов и решений.

Архитектура возможностей (Capability Architecture)

Архитектура возможностей, предоставляемая в течение спринта или даже нескольких спринтов, в зависимости от объема задачи, должна быть последовательно и циклично интегрирована в процесс поставки. Это более конкретная спецификация архитектуры, ориентированная на решение, включающая ABB, определенные на этапах B, C и D, и охватывающая как функциональные, так и нефункциональные аспекты реализуемого решения. Данные архитектурные спецификации затем дорабатываются на этапах E и F в качестве основы для SBB и их интеграции в искомые решения/услуги/продукты.

Ключевыми преимуществами архитектуры возможностей для Agile-предприятия являются:
- Предоставляет достаточную подробную детализацию архитектур более высокого уровня для определения имплементации и обеспечивает обратную связь с целью обновления вышестоящих уровней при необходимости.
- Разрабатывает проекты «точно в срок» (Just-In-Time, JIT), чтобы обеспечить «полосу разгона» для внедрения решений в рамках спринтов и предоставляет поддержку для их выполнения, минимизируя негативное влияние на процесс доставки.
- Определяет и уточняет пользовательские истории, которые будут реализованы различными Agile-командами.
- Обеспечивает контроль качества и соответствие требованиям при развертывании решения.
- Обеспечивает возможность отслеживания для подтверждения того, что первоначальные цели стратегической архитектуры достигнуты.
Архитектура возможностей — это спецификация решения, которое будет создано и развернуто по требованию Agile-командами в соответствии с архитектурными рекомендациями, метриками и соображениями совместимости.

Резюме

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

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

Перевод подготовлен для будущих студентов нового онлайн-курса «Архитектор Togaf 10». Поток стартует уже 28 августа, и к группе пока можно успеть присоединиться.
- Архитектура предприятия
- togaf 10
- Блог компании OTUS
- Управление продуктом
Архитектура предприятия

Архитектура предприятия (business architecture, enterprise architecture) — план предприятия (enterprise), который обеспечивает общее понимание организации (основные организационные и логистические решения), стратегические цели и тактические требования.

Терминология
- «Предприятие» является бизнес ассоциацией, состоящей из признанной совокупности взаимодействующих бизнес функций. Она способна работать как независимая, отдельная организация. Согласно такому определению, могут существовать предприятия в пределах предприятий. Например, организационная единица внутри общей корпоративной организации может быть рассмотрена как предприятие при наличии возможности независимого функционирования. Предприятие можно также рассматривать как «Расширенное предприятие (Extended Enterprise)»; это означает, что масштаб архитектуры предприятия может также включать взаимосвязи с внешними организациями. Такими как: поставщики, бизнес-партнеры и клиенты.
- «Архитектура» обеспечивает базовую концепцию. Она определяет и описывает платформу, необходимую предприятию для достижения своих задач и своего видения. Ее можно определить как: совокупность принципов, ориентиров, правил, моделей, стандартов и процессов, соответствующих требованиям бизнес стратегии и информации, направляющих выбор, создание и внедрение решений для будущих направлений бизнеса.
Моделирование процессов в организации

Задача моделирования «процессов» чаще всего появляется в следующих случаях:
- «Чтобы было» — для отчетности инвесторам, в том числе формального доклада Совету Директоров, или для покупки сертификата серии ISO 9000.
- Налаживание хода «регулярного менеджмента», когда делается попытка формализовать текущий оргбардак с целью провести хоть какую-то реорганизацию — т.е. для помощи менеджерам в принятии решений.
- При запуске нового сервисного продукта для договоренностей о том, как будет происходить работа множества разных служб в сложном «операционном дне»: кто что кому передаёт, и во сколько, чтобы успеть для какого-нибудь важного производственного цикла.
- Создание какой-то информационной системы. Быстро выясняется, что система живёт не в вакууме, а в организации, и требуется отмоделировать организацию, что и делают через «процессы».
Наиболее сложным подходом является моделирование процессов организации и создание «корпоративной информационной системы» (под которой понимается всё, что хоть как-то относится к компьютерам, т.е. сети, сервера, рабочие станции, данные и разнообразный софт). Люди, которые занимаются информационной системой хоть сколько-нибудь больших масштабов быстро приходят к тому, что им нужна «архитектура предприятия» (enterprise architecture) и тут же попадают в практику системной инженерии: рассматривается предприятие как система, в котором информационная система является подсистемой, а само рассмотрение ведется в терминах множества групп описаний.

Подходы к описанию архитектуры предприятия

Языки моделирования
- ArchiMate (ссылки) и архитектурный язык OpenGroup ArchiMate 2.0.
Критика архитектурных подходов

Опыт показывает, что все архитектурные подходы не слишком адекватны:
- группы описаний заставляют описать много лишнего, но не выявляют сущностного
- языки это сущностное не позволяют выражать
Поэтому продолжается поиск «сущностного» в организации, и адекватных описаний этого «сущностного». В последнее время выявлено несколько таких «сущностностей»:
1. Органиграмма как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то «органиграмма» оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
2. Структуры целей организации: например, Business motivation model (OMG BMM), или голдраттовское Strategic & Tactics Tree (S&TT).
3. Правила работы (Business rules), например OMG SBVR. «Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке».
4. Процессы
  - Процессы моделируется как цепочка поручений работы (напр., от запроса клиента до выполнения заказа), которая обязательно возращается (будь это внутренний «заказ», или «внешний», по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать «организационную сущность»: кто что кому поручает, саму «организованность людей». Представителем такого подхода к «процессам» является DEMO (Design & Engineering Methodology for Organizations).
  - Процессы документируются. Поскольку организация должна выполнять разные функции, эти функции нужно задокументировать. Этим занимаются главным образом люди, проникнувшиеся ISO 9000 и тамошнего понимания «процессов» как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции — это не работы («конструкция»), это функции, и об этом забывают. На диаграммах IDEF0 (наиболее часто используемый стандарт изображения функций, раньше это называлось SADT) в верхнем левом углу рисуется не «самый первый шаг», а «самая важная функция на листе». То есть «процесса», как развертки времени, в IDEF0 нет.
  - Документирование процесса во времени. Процесс, как развертка во времени из выполняемых шагов, или workflow («ход работ») это и есть BPM (business process management) — IDEF3 в наиболее древней нотации, в России хорошо известна нотация EPC (event-driven process chain) из ARIS, а главным современным стандартом является OMG BPMN 2.0, который поддерживают все «движки процессов». Каждую неделю очередная фирма заявляет о поддержке BPMN 2.0 моделирования, и компьютерного исполнения процессов, отмоделированных в BPMN 2.0.
  - Практики жизненного цикла (по-английски это иногда processes, а иногда practices). Развертка во времени тут — это сам жизненный цикл (life cycle), понимаемый как «последовательность стадий», где каждая стадия соответствует примерной одинаковости состояния системы в ходе работ по ее инженерии (замысел, проектирование, сооружение, эксплуатация и т.д. — хоть спички, хоть организации, хоть космодрома). А вот в ходе стадий выполняются те или иные практики, причем подробно не рассказывается, как их делать «шаг за шагом», зато указываются руководства, требования к квалификации сотрудников, выполняющих эти практики, нужный инструментарий, используемые языки и нотации представления информации. Именно из описания жизненного цикла можно узнать, используются ли в работе «итерации», или никаких итераций нет, и «возврат на доработку» — это ЧП. Стандарты такого описания — OMG SPEM, ISO 24744 и вновь разрабатываемый подход SEMAT. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
5. Проекты.
Примеры архитектуры предприятия
- Autodesk — изменение организационной структуры
- Spotify — отряды и племена
Что такое бизнес-архитектура Компании?

Бизнес-архитектура предприятия – это целостная и интегрированная модель фирмы, которая связывает стратегические, структурные, информационные, технологические и операционные аспекты Компании.

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

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

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

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

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

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

У Компании есть вариант купить готовые к использованию карты бизнес-возможностей — отраслевые модели или модели функциональных областей.

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