enterprise architeсture from ma - definition v 6-1

АРХИТЕКТУРА БИЗНЕСА И ИТ. ЧАСТЬ 1. ОПРЕДЕЛЕНИЕ АРХИТЕКТУРЫ

MARCUS AURELIUS LTD

Г. МОСКВА2016 ГОД, АВГУСТ

Ватикан. Королевская лестница.

Лоренцо Бернини

ЧАСТЬ 1. ОПРЕДЕЛЕНИЕ АРХИТЕКТУРЫ

Введение в Enterprise Architecture и нотацию моделирования Archimate 2.0-3.0

MARCUS AURELIUS LTD

АРХИТЕКТУРА - ЭТО СТРУКТУРНЫЙ ПОРЯДОК

системы

Мотивы

Цели

ДрайверыДрайверыДрайверыМотивыМотивы

Цели Цели Цели

проекты проекты программы программы функции функции

процессы процессы подразделения подразделенияinfo info info

системы системыданные данные данныеданные

УзлыЦОДыСУБД ШИНЫ Каналы

Ф Ф Ф Ф Ф Ф Ф Ф Ф

АРХИТЕКТУРА. ОПРЕДЕЛЕНИЕ

Архитектура - это набор ключевых компонент («строительных» блоков) сложной

системы, а также множество ключевых взаимосвязей между ними.

Так как мы рассматриваем архитектуру бизнес-систем (Enterprise Architecture), то

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

информационные компоненты

технологические компоненты

процессные компоненты, финансовые потоки

инфраструктурные компоненты

и другие.

Некоторые компоненты не следуют напрямую из системного подхода типа

«разделить целое на части и найти зависимости между частями».

Скорее они находятся на границе анализируемой системы (предприятия)

и внешней среды, в которой предприятие функционирует. К таким граничным

компонентам относятся:

цели и целевые установки

драйверы бизнеса

стейкхолдеры, мотивы стейкхолдеров

продукты компании

и другие.

MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор

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

АРХИТЕКТУРА: УПРОЩЕНИЕ ЧЕРЕЗ РАССЛОЕНИЕ.

В связи с тем, что бизнес-система может быть разделена на компоненты (или

подсистемы), каждая из которых может быть снова рассмотрена, как

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

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

Поэтому при отсутствии инструментов моделирования, в условиях

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

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

компонентов (каталог компонентов или группа каталогов) одной природы.

На сегодня в теории методологически проработаны модели следующих

слоев:

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

Бизнес: продукты, процессы, проекты, функции, подразделения, роли

ИТ: приложения, функции, данные, интерфейсы

Инфраструктура: каналы, узлы, серверы, базы данных

ТЕНДЕНЦИЯ: СВЯЗИ СТАЛИ ВАЖНЕЕ САМИХ КОМПОНЕНТ. ТИПЫ СВЯЗЕЙ

МЕЖДУ КОМПОНЕНТАМИ И КОЛИЧЕСТВО СВЯЗЕЙ ВОЗРОСЛО МНОГОКРАТНО.

По причине возрастания и усложнения связей между компонентами

анализируемой системы, а также в связи с тем, что часто «связи решают

всё», связи тоже стали объектом анализа, документирования,

типизирования и стандартизации.


АРХИТЕКТУРА: МНОГОУРОВНЕВЫЙСТРУКТУРНЫЙ ПОРЯДОК В ЭЛЕМЕНТАХ И СВЯЗЯХ МЕЖДУ НИМИ


Motivation & Delivery:

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

Расширение: проекты, программы, плато-gap

Business layer:

Структура процессов, функций, подразделений.

Структурирует бизнес-объекты

Структура создаваемого продукта

Application layer: обработка данных

Структурирует данные

Структурирует поведение систем

Структура интеграций

Infrastructure layer:

Структурирует сети.

Структурирует центры и узлы обработки

Структурирует системное программное

обеспечение

Цели-задачи-мотивы-проекты

Бизнес-процессы

Бизнес-функции

Бизнес-объекты

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

Инфраструктура

→ → →

АРХИТЕКТУРА БИЗНЕСА: АНАЛОГИИ СО СТРОИТЕЛЬСТВОМ

Цели

ДрайверыДрайверыДрайверы

Мотивы

Цели Цели Цели

проекты

программы

процессы процессы

подразделения

info

системысистемы

данные данные

УзлыЦОДыСУБД ШИНЫ Каналы

Ф

Ф

Мотивы

Мотивы

подразделения

данныефункции

функции

функции

функции

программы программы

функции

функции

функции

функции

функции

функции

Ф

Ф

процессы info

Ф Ф

АРХИТЕКТУРА. КЛЮЧЕВЫЕ КОМПЕТЕНЦИИ

Полное архитектурное описание предприятия предполагает полное и

изощренное описание всех компонент. Что значит «полное и подробное»?

Умение идентифицировать компоненты. Например, цели, драйверы,

ограничения, оценки, продукты, процессы, проекты, функции,

подразделения, роли, KPI, приложения, функции приложений, данные,

интерфейсы, каналы, узлы, серверы, базы данных, сооружения,

продукты. Сколько компонентов вы можете вычленить еще? А также на

сколько другие аналитики или члены вашего коллектива

понимают/разделяют эти стереотипы?

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

Умение делить (декомпозировать или дезагрегировать) компоненты на более мелкие

субкомпоненты: департаменты – на подразделения; процессы – на транзакции;

системы – на функции; информацию – на смыслы и данные; цели – на задачи и т.п.

Умение связывать компоненты. Здесь есть и умение - находить связи, и искусство –

находить виды связей (взаимосвязей).

Умение выделять ключевые компоненты, ключевые субкомпоненты и ключевые связи.

Возможно это и есть главное умение, которым обладают врожденные руководители и лидеры. Без него

задача построения архитектуры выливается в системно-математическое упражнение.


TOGAF

– МЕТОДОЛОГИЯ АРХИТЕКТУРНОГО МОДЕЛИРОВАНИЯ

TOGAF® - стандарт Open Group, предлагаемый в качестве архитектурной

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

TOGAF (The Open Group Architecture Framework) - это архитектурный

фреймворк, представляющий инструментарий для содействия в принятии,

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

Ключевым компонентом TOGAF является Architecture Development Method –

ADM (TOGAF 9 Part II: ADM).

ADM описывает процесс создания архитектуры предприятия.

ADM является руководством для архитекторов на нескольких уровнях:

• ADM предусматривает циклический ряд этапов разработки архитектуры: бизнес-

архитектуры, архитектуры информационных систем, технологической архитектуры.

• ADM предоставляет описание каждой архитектурной фазы в виде целей, подхода,

входов, шагов и выходов. Входы и выходы предоставляют собой определенные

архитектурные артефакты.

• ADM предоставляет механизм корреляции и контроля всех фаз через центральный

процесс ADM - управление требованиями.

Архитектуру, как методологию для бизнеса и ИТ, развивает Open Group и

ряд других некоммерческих институтов.

TOGAF на столько сосредоточен на методе построения архитектуры (ADM), на ее поддержании и вариантах встройки в бизнес,

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

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

TOGAF – это не указка, а линейка! И эта линейка никогда не скажет вам, сколько и где нужно отпилить или отрезать, или

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

ARCHIMATE 2.0-3.0

Спецификация ArchiMate 2.0 - это стандарт, разработанный консорциумом The Open Group в качестве языка архитектурного моделирования.

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

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

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

АРХИМЕЙТ ПОДСКАЗЫВАЕТ НАМ, КАКИМИ ПОНЯТИЯМИ И КАК НАДО МЫСЛИТЬ, ЧТОБЫ МЫСЛИТЬ АРХИТЕКТУРНО.


ин

фо

рм

аци

я

по

вед

ени

е

стр

укту

ра

ARCHIMATE – НОТАЦИЯ И ЯЗЫК МОДЕЛИРОВАНИЯ

Marcus Aurelius ltd.

ArchiMate - набор понятий и отражающих их артефактов

моделирования, нотация (язык) для графического

отображения и моделирования архитектуры.

Arсhimate предлагает модельные элементы (стереотипы)

для следующих слоёв предприятия:

Слой целей и мотивации: цели, мотивы, продукты,

заинтересованные лица, драйверы, ограничения

Слой бизнеса: процессы, функции, подразделения,

проекты

Слой ИТ: приложения, функции, данные, интеграции

Слой инфраструктуры: каналы, узлы, серверы, базы

данных

Слой 1

Слой 2

Слой 3

Слой 4

Архимейт предлагает три типа модельных элементов

в каждом слое:

Структурные элементы: задают структуру слоя

Поведенческие элементы: моделируют поведение системы или ее структурных элементов

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

поведения.

СТРУКТУРНЫЕ ЭЛЕМЕНТЫ УРОВНЯ БИЗНЕСА И IТ-ПРИЛОЖЕНИЙ

ТРИ ВИДА БАЗОВЫХ ЭЛЕМЕНТОВ: АКТИВНЫЕ, ПАССИВНЫЕ, ПОВЕДЕНИЕ

Пассивные элементы Поведенческие Активные элементы

БАЗОВЫЙ ПАТТЕРН

Meaning

Representation

Product

Contract

Business Object

Value

Data Object

Artifact

Business Service

Businessprocess /function /interaction

Event

Application Service

Infrastructure Service

System Software

Applicationfunction /interaction

Business Interface

Business Role

Application Interface

Application Component

Infrastructure Interface

Node

Device

Business Collaboration

Business Actor

Application Collaboration

Communication Path

Network

BusinessApplication

ApplicationTechnology

АРХИТЕКТУРА: ПРИМЕР ВЗАИМОСВЯЗИ МЕЖДУ СЛОЯМИ МОДЕЛИ


Цели-задачи-мотивы-проекты

Бизнес-процессыБизнес-функцииБизнес-объекты

→ → →

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

Stakeholder Driver

Goal

Constraint

Driver

Business Requiremen

t

System Requiremen

t

PrincipleConstraint

Business Service

Application Service

Value

Product

Work Package

ВИДЫ «АРХИТЕКТУРНЫХ» СВЯЗЕЙ

ВИДЫ СВЯЗЕЙ МЕЖДУ ОБЪЕКТАМИ

PassiveStructureElement

Service

BehaviorElement

Interface

ActiveStructureElement

accesses

accessed by

accesses

accessed by

used by

uses

realized by

realizes

assigned from assigned to

assigned from

assigned to

used by

uses

composes

composed of

used by

uses

triggered by / flow from triggers / flow to

МОДЕЛИРОВАНИЕ СВЯЗЕЙ И ОТНОШЕНИЙ ТАКЖЕ ВАЖНО, КАК И МОДЕЛИРОВАНИЕ САМОЙ СТРУКТУРЫ

КАК ПОДХОДИТЬ К ПОСТРОЕНИЮ АРХИТЕКТУРЫ

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

возможно использование двух подходов:

• Сверху вниз или от общего к частому. Основные

аналитические методы – декомпозиция и детализация.

• Снизу вверх или от частного общего. Основные

аналитические методы – агрегация и обобщение.

Практически у каждого крупного заказчика превалируют:

• на уровне штаб-квартиры: ToBe-проектирование сверху

вниз, то есть от новых/изменяющихся целей и задач

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

систем.

• на местах (в регионах): подход снизу вверх, то есть от

имеющихся систем и функционала к новым возможностям

для бизнеса.

+7 495 922 12 40. Рудь Виктор

ПРАВИЛЬНОЕ ПРОЕКТИРОВАНИЕ ЗАКЛЮЧАЕТСЯ В КОМБИНАЦИИ ДВУХ ПОДХОДОВ, А НЕ В ОДНОЗНАЧНОМ

ПРЕДПОЧТЕНИИ ОДНОГО ИЗ НИХ.

TOGAF ОБ АКТУАЛИЗАЦИИ И ПОДДЕРЖАНИИ АРХИТЕКТУРЫ


Поддержание архитектуры в актуальном состоянии – это дискретный эволюционный процесс. Актуализация архитектуры

выполняется в отдельных доменах, которые каждое предприятие определяет для себя самостоятельно. Таким доменом может быть:

• бизнес-процесс,

• управление или департамент, бизнес-блок,

• бизнес-функция,

• бизнес-единица или деятельность в рамках определенной линейки продуктов,

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

Architecture Continuum

GenericArchitectures

SpecificArchitectures

Обобщение с целью переиспользования

Адаптация под конкретную задачу

ПРАВИЛЬНОЕ УПРАВЛЕНИЕ АРХИТЕКТУРОЙ – ЭТО УПРАВЛЕНИЕ ABB (ARCHITECTURE BUILDING BLOCKS) – ЗАКОНЧЕННЫЕ

АРХИТЕКТУРНЫЕ ФРАГМЕНТЫ, СОВОКУПНОСТЬ КОТОРЫХ СОСТАВЛЯЕТ ВСЮ АРХИТЕКТУРУ ПРЕДПРИЯТИЯ. ОТДЕЛЬНЫЕ ABB МОГУТ

УСТАРЕВАТЬ С ТОЧКИ ЗРЕНИЯ ИХ ВНУТРЕННЕГО УСТРОЙСТВА, НО ОСТАВАТЬСЯ НЕИЗМЕННЫМИ В ТОМ, КАК ОНИ ВХОДЯТ В ОБЩУЮ

КОНСТРУКЦИЮ ПРЕДПРИЯТИЯ.

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

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

Следует также отличать Architecture Continuum от Solution Continuum. Последний представляет собой набор конкретных

реализаций тех или иных ABB в виде законченных развёрнутых решений (SBB – Solution Building Blocks). SBB не абстракты и

четко документированы в силу их физической природы. Это лежит в основе их достаточно простой актуализации.

ARCHIMATE & BPMN

ArchiMate® 3.0 Specification. Copyright © 2012-2016 The Open Group

The BPMN Standard

Both the ArchiMate language and BPMN can be used for modeling business processes. Their aims are different,

however. ArchiMate notation is typically used for high-level processes and their relations to the enterprise context, but is

not intended for detailed workflow modeling, whereas BPMN supports detailed sub-process and task modeling down to

the level of executable specifications, but lacks the broader enterprise context, for example, to model the application

services that support a process or the goals and requirements it has to fulfill.

Both languages share the concepts of (business) process and event. In the ArchiMate notation there is a single business

process element that may be decomposed in other processes that are related using flow and triggering relationships,

possibly using junctions to represent more complex connections. BPMN has a more fine-grained set of elements, with

various types of events, tasks, and gateways. Its metamodel also distinguishes explicitly between process and sub-

process (although it lacks a graphical representation of a business process itself). The BPMN concept of participant (or

pool) and the ArchiMate concepts of business role or business actor (or application component for automated processes)

also correspond.

In a typical scenario, both languages can be used in conjunction. Mapping from ArchiMate notation down to BPMN is

fairly straightforward. The other way around loses the detailed elements of BPMN. Moreover, there are structural

differences between the languages that preclude a direct concept-to-concept mapping and may merit a pattern-based

approach.

http://pubs.opengroup.org/architecture/archimate3-doc/copyright.html

ARCHIMATE & BMM

The BMM Standard

The ArchiMate strategy and motivation elements have been inspired partly by the Business Motivation Model (BMM). BMM

distinguishes between means, ends, and influencers and assessments. It provides fairly detailed concepts for these categories.

The ArchiMate course of action element corresponds directly with the course of action element in BMM, whereas its directive

concepts can be modeled with the ArchiMate principle, requirement, and constraint elements.

BMM concepts for modeling ends are typically mapped onto the ArchiMate goal element. Its influencers correspond to the

ArchiMate element of driver, whereas its assessments map directly onto the ArchiMate assessment element.

Although a mapping between many of the ArchiMate motivation and implementation elements and BMM concepts is possible,

BMM provides a more detailed, fine-grained description of business motivation. Where the ArchiMate language aims to cover a

broad scope and interlink various domains, these more specialized languages zoom in on the details of their specific domains.



ARCHIMATE & UML

The UML Standard

The ArchiMate language has derived a number of concepts from UML. For other concepts, straightforward correspondences can be defined.

In the Business Layer, the ArchiMate business process concept can be mapped onto UML activity diagrams, where more detailed specifications

of such processes can be given (although BPMN would be the preferred language for detailed process and workflow modeling). The ArchiMate

business actor and role concepts can both be mapped onto UML actors, although the latter can also be used for modeling automated actors.

Business collaborations have been inspired by collaborations as defined in the UML standard, although the UML collaborations apply to

components in the Application Layer.

In the Application Layer, the application component element corresponds to the UML component. This facilitates the direct linkage between

higher-level Enterprise Architecture models described in ArchiMate notation and lower-level solution architecture and implementation models in

UML in one continuous development chain. In less direct manner, the ArchiMate application function concept can be mapped onto UML activity

diagrams, and an application service to a use-case diagram. Application collaborations also correspond to UML collaborations.

Many of the elements of the ArchiMate Technology Layer correspond directly to UML. The node, artifact, device, system software, and path

elements have a direct counterpart in UML (where system software is called execution environment).

In addition to these elements, many relationships in the ArchiMate language have close ties to UML as well. The ArchiMate association,

composition, aggregation, specialization, and realization relationships have a direct counterpart in UML.

There are also some notable differences between the two languages. The ArchiMate serving relationship (formerly used by) is different from UML

dependency. Although their notations are similar, their directions are different. UML dependency is often used to model, for example, function

calls in software programs, but in ArchiMate notation, the direction of the serving relationship denotes the direction of service delivery,

independent of whether this service is called by the user or offered pro-actively by the provider. At the architectural level at which the ArchiMate

language is aimed, the run-time operational details of such call graphs is less important than the more stable and generic notion of service

provision.

This also points to another important difference: UML does not have a separate service concept, since in its object-oriented paradigm the

behavior expressed by a service is encapsulated within the interface offering that behavior (i.e., its operations). The ArchiMate language

differentiates between interfaces and the services they provide to allow, for example, specifying that the same service is offered through multiple

interfaces. Hence, an ArchiMate application interface does not equate directly with a UML interface.



ДЛЯ ИССЛЕДОВАНИЯ АРХИТЕКТУРЫ НУЖЕН ИНСТРУМЕНТ

Поддержка стандарта Archimate 2.0

Поддержка стандарта BPMN

Возможность разработки любой (!) нотации

Возможность доработки встроенных нотаций

Конструирование любой метамодели

Возможность устанавливать связи между моделями

Связывание объектов атрибутивно или графически

Коллективная работа на общем сервере

Vbasic-образный язык разработки скриптов для автоматизации

рутинный операций

Поддержка TOGAF

НОВИЧКИ БУДУТ ИСКАТЬ В ИНСТРУМЕНТАХ ГОТОВЫЕ ШАБЛОНЫ МОДЕЛИРОВАНИЯ И ОТЧЕТНОСТИ. QPR НЕ ДЛЯ НИХ.

ОПЫТНЫЕ АРХИТЕКТОРЫ ВЫБЕРУТ QPR

ЗА ЕГО НЕОГРАНИЧЕННУЮ ГИБКОСТЬ В РЕШЕНИИ ВСЕГДА НЕПРЕДСКАЗУЕМЫХ ОСОБЕННОСТЕЙ И ЗАДАЧ БИЗНЕСА.

Продукт компании QPR - Enterprise Аrchitect. Возможности:

Enterprise Architect – единая интегрированная среда,

в которой интегрированы: системы, функции, интерфейсы, инфопотоки, процессы, цели, задачи и т.п. зафиксированные в виде

артефактов системы и иллюстрированные интерактивными диаграммами.


КОГДА НУЖНО ПОНИМАНИЕ АРХИТЕКТУРЫ?

Понимание архитектуры необходимо тогда, когда вы планируете изменить/перестроить вашу

конструкцию (ваш бизнес).

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

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

повышения своей результативности.

Некоторые люди являются от природы архитекторами или в силу возраста/опыта

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

производства.

MARCUS AURELIUS LTD

АРХИТЕКТУРА. ЕЩЕ РАЗ ОБ ОПРЕДЕЛЕНИИ

Архитектура - это набор ключевых компонент («строительных» блоков) сложной системы, а также

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

Так как мы рассматриваем архитектуру бизнес-систем (Enterprise Architecture), то компоненты будут

весьма специфичными и релевантными именно для бизнеса:


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

пищеварительная система, тренированный мозг и мышцы и т.п. Чем детальнее исследование

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

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

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

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

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

Текущие задачи, которые берёт на себя методология:

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

спланировать и контролировать трансформационный переход от AsIs-архитектуры к ToBe-архитектуре.

информационные компоненты

технологические компоненты

процессные компоненты, финансовые

потоки

инфраструктурные компоненты

цели и целевые установки

драйверы бизнеса

стейкхолдеры, мотивы стейкхолдеров

продукты компании

и другие.

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

такого сложного, как предприятие.

- Архитекторы-трансформаторы (руководители): интуитивно или на основе опыта они выделяют ключевые компоненты/связи бизнеса и

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

ЕСТЬ ЛИ ЦЕННОСТЬ В АРХИТЕКТУРНОМ МОДЕЛИРОВАНИИ, ЕСЛИ TO-BE МОДЕЛЬ МОГУТ ПОСТРОИТЬ ТОЛЬКО ОТДЕЛЬНЫЕ ПРОФЕССИОНАЛЫ?


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

себя практика АРХИТЕКТУРНОГО МОДЕЛИРОВАНИЯ, в основе которой лежит принцип расслоения анализируемой сложной

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

между компонентами различных слоёв.

Все эти компоненты (организованные в виде слоёв) и ранее подвергались анализу дизайнерами изменений и практиками

моделирования: уже давно существует множество нотаций и методологий в моделировании данных, целей, процессов, систем,

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

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

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

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

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

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

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

координировать столь сложные трансформации. Примечание: построение новых сложных систем/комплексов/отраслей или

долгосрочное отраслевое планирование имеет в своей основе именно трансформационную природу, так как приводит к

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

Могут ли нынешние руководители всегда быть лидерами изменений? – не всегда это просто, так как изменения затрагивают многие

и многие аспекты деятельности предприятия. Поэтому методология архитектурного моделирования позволяет не только расслоить

текущую AsIs ситуацию и спланировать изменения в каждом слое, но также собрать предприятие в единую новую ToBe-

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

MARCUS AURELIUS LTD.

КОНТАКТЫ ДЛЯ СВЯЗИ

Рудь Виктор Директор по консалтингу

ООО «МАРК АВРЕЛИЙ»

http://www.consulo.ru

E-mail: v.rud @consulo.ru

Телефон: +7 (495) 922-12-40

Не отказывайся от помощи, особенно когда это связано с исполнением долга.

Многое из того, что не удаётся сделать в одиночку, может быть легко достигнуто, если действовать сообща…

Марк Аврелий


http://www.consulo.ru/

WWW.MARCUS-AURELIUS.RU

Рудь Виктор Геннадиевич

Директор по консалтингу

ООО «МАРК АВРЕЛИЙ»

e-mail: v.rud @consulo.ru

Телефон: +7 (495) 922-12-40

Marcus Aurelius ltd.

Управление архитектурой систем и предприятия

Концептуальное проектирование

Реинжиниринг процессов

Дизайн информационных систем

Бизнес-анализ

Дизайн и поддержание автоматизированных

каталогов услуг

Проведение тендеров на выбор программного

обеспечения

Обучение по архитектурным методологиям

Управление требованиями

Разработка Требований, Тех.Заданий,

Архитектурных решений и концепций

Организационный дизайн

Процессное управление

Проработка KPI процессов и подразделений

Управление проектом

Планирование проекта и ресурсов

Создание и контроль процессной архитектуры

Создание и контроль функциональной архитектуры

Создание и контроль информационной архитектуры

Разработка учебных материалов

Обучение ключевых пользователей

Нормирование численности подразделений и

оптимизация орг.штатной структуры

Реинжиниринг процессов

Подготовка процессов и функций к передаче в

аутсорсинг

Виды услуг компании: Виды помощи в больших проектах:

ЭКСПЕРТИЗА И УСЛУГИ КОМПАНИИ «МАРК АВРЕЛИЙ»


КЛИЕНТЫ КОМПАНИИ «МАРК АВРЕЛИЙ»


СЕВЕРНЫЕ

ПРИИСКИ

enterprise architeсture from ma - definition v 6-1

Documents