MA EA -Архитектура ИТ v 4VR
0 likes695 views
Документ описывает архитектуру ИТ распределенной компании Marcus Aurelius Ltd с акцентом на методологию ArchiMate и ее применение для моделирования сложных систем. Он раскрывает многоуровневую структуру архитектуры, включая бизнес- и технологические слои, а также факторы, влияющие на управление и принятие решений в условиях сложной ИТ-среды. Также упоминается использование стандартов TOGAF для разработки корпоративной архитектуры и необходимость актуализации информации о системах и их интеграциях.
MA EA -Архитектура ИТ v 4VR
- 1. АРХИТЕКТУРА ИТ РАСПРЕДЕЛЕННОЙ КОМПАНИИ ФЕДЕРАЛЬНОГО УРОВНЯ MARCUS AURELIUS LTD Г. МОСКВА 2015 ГОД, СЕНТЯБРЬ Ватикан. Королевская лестница. Лоренцо Бернини
- 2. СТРАНИЦА 2 СОДЕРЖАНИЕ MARCUS AURELIUS LTD. 1. ARCHIMATE – МЕТОДОЛОГИЯ & НОТАЦИЯ МОДЕРИРОВАНИЯ 2. ПРОЕКТ И ЕГО ПРЕДПОСЫЛКИ. ОТ ХАОСА К ИНВЕНТАРИЗАЦИИ 3. МЕТАМОДЕЛЬ ДЛЯ МОДЕЛИРОВАНИЯ ИТ-АРХИТЕКТУРЫ 4. ВИДЫ ДИАГРАММ, КОТОРЫЕ ЗАДЕЙСТВОВАНЫ В ПРОЦЕССЕ МОДЕЛИРОВАНИЯ 5. ПОРЯДОК АКТУАЛИЗАЦИИ АРХИТЕКТУРЫ 6. ПОЛЕЗНЫЕ ВОЗМОЖНОСТИ СИСТЕМЫ QPR ENTERPRISE ARCHITECT
- 3. СТРАНИЦА 3 РАЗДЕЛ 1. МЕТОДОЛОГИЯ И НОТАЦИЯ Введение в архитектуру и несколько слов о нотации моделирования Archimate 2.0 MARCUS AURELIUS LTD
- 4. СТРАНИЦА 4АРХИТЕКТУРА - ЭТО СТРУКТУРНЫЙ ПОРЯДОК системы Мотивы Цели ДрайверыДрайверыДрайверыМотивыМотивы Цели Цели Цели проекты проекты программы программы функции функции процессы процессы подразделения подразделенияinfo info info системы системыданные данные данныеданные УзлыЦОДыСУБД ШИНЫ Каналы Ф Ф Ф Ф Ф Ф Ф Ф Ф
- 5. СТРАНИЦА 5 АРХИТЕКТУРА. ОПРЕДЕЛЕНИЕ Marcus Aurelius ltd. Aрхитектура - набор структурных компонент сложной системы и всё множество взаимосвязей между компонентами. Мы рассматриваем архитектуру бизнес-систем (Enterprise Architecture). В связи с тем, что бизнес-система может быть разделена на подсистемы, каждая из которых может быть снова рассмотрена, как система, то архитектура моделируется отдельными слоями (послойное представление архитектуры). На сегодня в теории методологически проработаны модели следующих слоев: Контекст и целеполагание: цели, драйверы, ограничения, оценки … Бизнес: продукты, процессы, проекты, функции, организация ИТ: приложения, функции и данные Инфраструктура: каналы, узлы, серверы, базы данных ТЕНДЕНЦИЯ: КОЛИЧЕСТВО И ТИПЫ СВЯЗЕЙ МЕЖДУ ЭЛЕМЕНТАМИ (КОМПОНЕНТАМИ) ВОЗРОСЛО МНОГОКРАТНО.
- 6. СТРАНИЦА 6 АРХИТЕКТУРА: МНОГОУРОВНЕВЫЙ СТРУКТУРНЫЙ ПОРЯДОК В ЭЛЕМЕНТАХ И СВЯЗЯХ МЕЖДУ НИМИ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Motivation & Delivery: Структурирует цели, мотивы и факторы влияния Расширение: проекты, программы, плато-gap Business layer: Структура процессов, функций, подразделений. Структурирует бизнес-объекты Структура создаваемого продукта Application layer: обработка данных Структурирует данные Структурирует поведение систем Структура интеграций Infrastructure: Структурирует сети. Структурирует центры и узлы обработки Структурирует системное программное обеспечение Цели-задачи-мотивы- проекты Бизнес-процессы Бизнес-функции Бизнес-объекты Архитектура систем и данных Инфраструктура → → →
- 7. СТРАНИЦА 7 информация поведение структура ARCHIMATE – МЕТОДОЛОГИЯ & НОТАЦИЯ МОДЕЛИРОВАНИЯ Marcus Aurelius ltd. ArchiMate - набор понятий и отражающих их артефактов моделирования, нотация (язык) для графического отображения и моделирования архитектуры. Примеры структурных элементов, из которых состоят модели в нотации Arhimate: цели, мотивация, продукты требования, ограничения, драйверы процессы, функции, подразделения, проекты приложения, функции, данные инфраструктура, каналы, узлы, серверы, базы данных Моделируемые компоненты распределяются: по слоям архитектуры: цели&мотивы, бизнес, IT, инфраструктура. по аспектам моделирования: структура, поведение, информация. ARCHIMATE ПРЕДСТАВЛЯЕТ БОЛЕЕ 40 ТИПОВ ЭЛЕМЕНТОВ ДЛЯ МОДЕЛИРОВАНИЯ. ЧТО ВЫБРАТЬ? Слой 1 Слой 2 Слой 3 Слой 4
- 8. СТРАНИЦА 9 ARCHIMATE 2.0 Спецификация ArchiMate 2.0 это стандарт, разработана компанией The Open Group, в качестве языка архитектурного моделирования ArchiMate. Стандарт содержит формальное определение ArchiMate как графического конструкторского языка, а также элементов для описания взаимосвязанных архитектур и специфицированных viewpoints для типовых заинтересованных лиц. На сегодня Archimate поддерживается большинством поставщиков ПО для архитектурного описания предприятий. Однако это не означает, что все инструменты одинаково удобны для архитектурного моделирования. ARCHIMATE – ЭТО ЯЗЫК, НА КОТОРОМ РЕШАЮТСЯ ЗАДАЧИ УРОВНЯ ПРЕДПРИЯТИЯ
- 9. СТРАНИЦА 10 10 Менеджер проекта: это состав ключевых работ ИТ: это workflow Менеджер: это верхнеуровневая схема деятельности! Консультант: это поток функций? Аналитик: это точка зрения на процесс! КАК ИНАЧЕ ОБ ЭТОМ ДОГОВОРИТЬСЯ? - НУЖЕН СТАНДАРТ! Отдел бизнес- процессов: это процесс!
- 10. СТРАНИЦА 11 ЧЕМ ПРИХОДИТСЯ УПРАВЛЯТЬ? MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор ДВЕ ГЛАВНЫХ ЧЕРТЫ СОВРЕМЕННОГО УПРАВЛЕНИЯ: Нахождение релевантной информации в безумном потоке данных. Выделение базовых элементов и их взаимосвязей. Если раньше приходилось управлять непосредственно людьми, то сейчас управление свелось к умению понимать и интерпретировать многочисленную информацию, поступающую регулярно и спорадически из различных источников. Ключевым фактором успеха управления становится способность реагировать на информационный поток, продолжая видеть в нем отдельные объекты управления, субъектов управления, возможности и риски, многочисленные роли и взаимосвязи между ними. ЭЛЕМЕНТЫ УПРАВЛЕНИЯ СТАЛИ АТОМАРНЫМИ, ПРЕДСКАЗУЕМЫМИ, ГИБКИМИ: ТИПЫ СВЯЗЕЙ МЕЖДУ ЭЛЕМЕНТАМИ УПРАВЛЕНИЯ И ИХ КОЛИЧЕСТВО ВОЗРОСЛИ МНОГОКРАТНО !!! Примечание: объектно-ориентированный подход приучил нас думать об объектах как об экземплярах определенного класса, имеющего предопределенный набор свойств. Теперь свойства объекта в большей степени определяются не его атрибутами, а отношениями в которых он участвует в той или иной роли. Понятие класса существенно размывается, а классификация объектов производится не в момент его регистрации в системе, а в ходе всего жизненного цикла.
- 11. СТРАНИЦА 12 АРХИТЕКТУРА: ВИДЫ СВЯЗЕЙ ВИДЫ СВЯЗЕЙ МЕЖДУ ОБЪЕКТАМИ Passive Structure Element Service Behavior Element Interface Active Structure Element 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 МОДЕЛИРОВАНИЕ СВЯЗЕЙ И ОТНОШЕНИЙ ТАКЖЕ ВАЖНО, КАК И МОДЕЛИРОВАНИЕ САМОЙ СТРУКТУРЫ
- 12. СТРАНИЦА 13 TOGAF & ARCHIMATE: ИНСТРУМЕНТЫ УПРАВЛЕНИЯ 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 - управление требованиями.
- 13. СТРАНИЦА 14 АРХИТЕКТУРА: ПРИМЕР ВЗАИМОСВЯЗИ МЕЖДУ СЛОЯМИ МОДЕЛИ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Цели-задачи-мотивы- проекты Бизнес-процессы Бизнес-функции Бизнес-объекты → → → Архитектура систем и данных Stakeholder Driver Goal Constraint Driver Business Requiremen t System Requiremen t PrincipleConstraint Business Service Application Service Value Product Work Package
- 15. СТРАНИЦА 16 СТРУКТУРНЫЕ ЭЛЕМЕНТЫ УРОВНЯ БИЗНЕСА И ПРИЛОЖЕНИЙ ТРИ ВИДА БАЗОВЫХ ЭЛЕМЕНТОВ: АКТИВНЫЕ, ПАССИВНЫЕ, ПОВЕДЕНИЕ Пассивные элементы Поведенческие Активные элементы
- 16. СТРАНИЦА 17 ВЫГОДЫ АРХИТЕКТУРНОГО МОДЕЛИРОВАНИЯ Основано на данных Boehm, Valerdi, Honour по теме системной инженерии ОТНЕСИТЕСЬ К ЭТИМ ЦИФРАМ НЕ КАК К УКАЗАНИЯМ, А КАК ОСНОВАНИЮ ДЛЯ РАЗМЫШЛЕНИЯ. Размер проекта или масштаб деятельности Возможный рост затрат (отклонение затрат от запланированного значения) Рекомендуемые затраты на архитектурное моделирование Мелкие ~10-20% 5% Средние ~40% 20% Крупные ~60% 30% Очень крупные ~90% 40%
- 17. СТРАНИЦА 18 РАЗДЕЛ 2. ПРОЕКТ И ЕГО ПРЕДПОСЫЛКИ. Что послужило основанием для руководства компании инициировать проект? Общая характеристика проекта. MARCUS AURELIUS LTD ОТ ХАОСА К ИНВЕНТАРИЗАЦИИ
- 18. СТРАНИЦА 19 КАК СПРАВИТЬСЯ СО СЛОЖНОСТЬЮ? КАКИМ МОЖЕТ БЫТЬ КАЧЕСТВО И СКОРОСТЬ ПРИНЯТИЯ РЕШЕНИЙ В ТАКОЙ СИТУАЦИИ? В компании более 20 ЦОД’ов и до 100 мест развёртывания приложений В компании более 1000 систем и их инсталляций Тысячи функций Тысячи интеграционных взаимодействий Десятки вендоров и интеграторов Гигабайты не актуальной документации Десятки не документированных систем собственной разработки Десятки параллельных проектов по модернизации и интеграции систем (более 12 проектных офисов по управлению проектами развития) Неужели всё это нужно бизнесу? Кому? Когда? Где? Как это связано с бизнес- процессами компании? MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 19. СТРАНИЦА 20 ФАКТОРЫ ВЛИЯНИЯ НА ИТ Функции компании Компетенции Цели KPI Процессы Проекты Capability/Service Знания Персонал Ожидания клиентов Ожидания акционеров… Бизнес-модель: партнеры, продукт, цена, ресурсы, каналы, доходы, затраты. MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 20. СТРАНИЦА 21 КАК УСКОРИТЬ ПРИНЯТИЕ РЕШЕНИЙ? Marcus Aurelius ltd. МОМЕНТАЛЬНО ПОНИМАТЬ СИТУАЦИЮ & БЫСТРО ПРИНИМАТЬ РЕШЕНИЯ ОБ ИЗМЕНЕНИИ 3 человека – 67 секунд 20 человек – 2 секунды
- 21. СТРАНИЦА 22МЫ МОДЕЛИРУЕМ ТОЛЬКО ИТ-АРХИТЕКТУРУ системы Мотивы Цели ДрайверыДрайверыДрайверыМотивыМотивы Цели Цели Цели проекты проекты программы программы функции функции процессы процессы подразделения подразделенияinfoinfo info системы системыданные данные данныеданные УзлыЦОДыСУБД ШИНЫ Каналы Ф Ф Ф Ф Ф Ф Ф Ф Ф
- 22. СТРАНИЦА 23 Application Component – одна инсталляция автоматизированной информационной системы Функция системы – элемент поведения системы, отражающий определенный паттерн обработки данных или контроля за ходом бизнес-процесса Интерфейс системы – «механизм» предоставления определенного поведения системы наружу. Application Interaction – взаимодействие систем, как правило – поток данных или вызов функций. ИСПОЛЬЗУЕМЫЕ В ПРОЕКТЕ ТИПЫ СТРУКТУРНЫХ ЭЛЕМЕНТОВ Процессы – элементы взаимоувязанных цепочек действий. Функция подразделения – предписанный подразделению вид деятельности Node – центры обработки данных Data Object – элемент представления модели данных MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор КАЖДЫЙ ОБЪЕКТ ИМЕЕТ ОТ 5 ДО 20 АТРИБУТОВ И НЕСКОЛЬКО ВИДОВ СВЯЗЕЙ Из четырех архитектурных слоёв мы используем только слой приложений и данных
- 23. СТРАНИЦА 24 Домен1Домен2 СИСТЕМНЫЙ ЛАНДШАФТ: СЛОЙ ИНФОРМАЦИОННЫХ СИСТЕМ СИСТЕМЫ - БАЗОВЫЙ СЛОЙ - СЛОЙ ПРИВЯЗКИ ПРОЧИХ СТРУКТУРНЫХ ЭЛЕМЕНТОВ МОДЕЛИ Автоматизиров анная система расчетов Личный кабинет пользователя Финансовая система Логистическая система Система контроля датчиков Система приема платежей HR Система сопряжения с оборудованием Система учета инцидентов Система расчета мощности Система мониторинга сети Система CRM Система поддержки оператора ЦОО Учет основных средств Учет производственн ых мощностей Единая база знаний Маркетинговый портал Система автоматизации проектирования
- 24. СТРАНИЦА 25 ПАСПОРТИЗАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ По каждой информационной системе в формате Excel составляется паспорт системы. Паспорт системы содержит: Лист 0. История создания и изменений паспорта Лист 1. Общие данные по системе и местам ее инсталляции Лист 2. Функции системы (функции 1-2-3-го уровня и комментарии к ним) Лист 3. Интеграции систем Лист 4. Состав модулей CRM Личный кабинет пользователя Логистическая система Система сопряжения с оборудованием Система автоматизации проектирования ПАСПОРТ СИСТЕМЫ ЯВЛЯЕТСЯ ИНСТРУМЕНТОМ СБОРА ИНФОРМАЦИИ И КОММУНИКАЦИИ С ВЛАДЕЛЬЦАМИ СИСТЕМЫ
- 25. СТРАНИЦА 26 КАРТОЧКА ИНФОРМАЦИОННОЙ СИСТЕМЫ Название поля 1 ID системы 2 Полное наименование системы 3 Краткое имя для схем 4 Краткое описание системы 5 Место текущей физической установки ИС 6 Уровень унификации решения 7 Количество установок 8 Аналитик 9 Класс ИС 10 Целевая архитектура (признак) 11 Ответственный департамент в УК 12 Локальный разработчик ИС 13 Вендор ИС 14 Интегратор ИС Название поля 15 Язык разработки ИС или СУБД 16 Оценка имеющейся документации 17 Штат специалистов по ИС 18 Статус реализации ИС: • промышленная экслплуатация • архивная система • система на стадии внедрения • выведена из эксплуатации 19 Куда выгружается отчетность? 20 Ответственное лицо по ИС • ФИО • Телефон/Email • Подразделение ответственного лица 21 Контактное лицо по ИС • ФИО • Телефон/Email 22 Заказчик ИС • ФИО • Телефон/Email • Подразделение ответственного лица ПО КАЖДОЙ (!) СИСТЕМЕ ЗАПОЛНЯЕТСЯ ФОРМУЛЯР (КАРТОЧКА)
- 26. СТРАНИЦА 27 Вендор ПРЕДСТАВЛЕНИЯ: ОТЧЕТЫ ПО ИНФОРМАЦИОННЫМ СИСТЕМАМ НА ОСНОВАНИИ ДАННЫХ ПО СИСТЕМАМ И ДРУГИМ ЭЛЕМЕНТАМ МОДЕЛИ, ВКЛЮЧАЯ СВЯЗИ ЭЛЕМЕНТОВ, МЫ СТРОИМ ВЫБОРКИ/ОТЧЕТЫ ДЛЯ ЗАИНТЕРЕСОВАННЫХ ЛИЦ
- 27. СТРАНИЦА 28 Регион 2Регион 1 Домен 2 Домен 1 СИСТЕМНЫЙ ЛАНДШАФТ: РЕГИОНАЛЬНАЯ ДИВЕРСИФИКАЦИЯ С ПОМОЩЬЮ РЕГИОНАЛЬНЫХ КАРТ МЫ ПОКАЗЫВАЕМ РАЗЛИЧИЯ СИСТЕМНОГО ЛАНДШАФТА В РАЗЛИЧНЫХ ФУНКЦИОНАЛЬНЫХ ДОМЕНАХ МЕЖДУ РАЗЛИЧНЫМИ РЕГИОНАМИ ИЛИ ОТДЕЛЕНИЯМИ КОМПАНИИ. Автоматизирова нная система расчетов Личный кабинет пользователя Финансовая система Логистическая система Система приема платежей Система сопряжения с оборудованием Система расчета мощности Система CRM Учет основных средств Учет производственн ых мощностей Единая база знаний Маркетинговый портал (вендор X) Система автоматизации проектирования Автоматизирова нная система расчетов Личный кабинет пользователя Финансовая система Логистическая система Система приема платежей Система сопряжения с оборудованием Система расчета мощности ГИС Система CRM Учет основных средств Учет производственн ых мощностей Единая база знаний Маркетинговый портал (вендор Y) Система автоматизации проектирования Система мониторинга сети MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 28. СТРАНИЦА 29 МОДЕЛЬ/СЛОЙ ДАННЫХ ПО КАЖДОЙ (!) СИСТЕМЕ СОЗДАЁТСЯ ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ ИЛИ МОДЕЛЬ ВЗАИМОСВЯЗИ ОСНОВНЫХ БИЗНЕС-СУЩНОСТЕЙ.
- 29. СТРАНИЦА 30 СЛОЙ: ФУНКЦИИ Application Y (информационная система) Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Х (информационная система) Application Function Application Function Application Function Application Function Application Function Application Function ПО КАЖДОЙ (!) СИСТЕМЕ СОЗДАЁТСЯ ЕЁ ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ НА 2-3-4 УРОВНЯХ МОДЕЛИРОВАНИЯ В ЗАВИСИМОСТИ ОТ ПРЕДСТОЯЩИХ ЗАДАЧ ПО ФУНКЦИОНАЛЬНОМУ СРАВНЕНИЮ СИСТЕМ ИЛИ РАЗВИТИЮ/ТРАНСФОРМАЦИИ СИСТЕМНОГО ЛАНДШАФТА Сравнение функций, поиск дублирования функционала
- 30. СТРАНИЦА 31 СЛОЙ ИНТЕГРАЦИЙ: ИНФОПОТОКИ МЫ КЛАССИФИЦИРУЕМ ВСЕ МЕЖСИСТЕМНЫЕ ВЗАИМОДЕЙСТВИЯ ПО ПРИЗНАКУ ПЕРЕДАВАЕМОЙ ИНФОРМАЦИИ
- 31. СТРАНИЦА 32 СЛОЙ ИНТЕГРАЦИЙ: ПЕРЕХОД К СЕРВИСАМ Сервис управления заказами Сервис управления клиентами Сервис управления услугами НА ОСНОВАНИИ РЯДА ФАКТОРОВ, ОТДАВАЯ ПРИОРИТЕТ ГРУППИРОВКЕ ИНФОПОТОКОВ, МЫ ВЫДЕЛЯЕМ БУДУЩИЕ СЕРВИСЫ ЕДИНОЙ ИТ-АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ
- 32. СТРАНИЦА 33СЛОЙ ИНТЕГРАЦИЙ: ПЕРЕХОД К СЕРВИСАМ ФУНКЦИИ ПРИЛОЖЕНИЯ ОБЕСПЕЧИВАЮЩЕЕ ПРИЛОЖЕНИЕ СЕРВИС ДОСТУПНОСТЬ СЕРВИСА для ИСПОЛЬЗОВАНИЯ СЕРВИС ИНКАПСУЛИРУЕТ ФУНКЦИИ (ПОВЕДЕНИЕ) И РЯД РАЗРОЗНЕННЫХ ИНТЕГРАЦИЙ В ОДИН УНИФИЦИРОВАННЫЙ И ДОСТУПНЫЙ ДЛЯ ОБЩЕГО ИСПОЛЬЗОВАНИЯ КОМПОНЕНТ С ОТКРЫТЫМ ИНТЕРФЕЙСОМ ДОСТУПА К НЕМУ ДАННЫЕ ПРИЛОЖЕНИЯ
- 33. СТРАНИЦА 34 Регион УРАЛ Регион СИБИРЬ Управляющая компания ОТДЕЛЬНЫЕ ЭЛЕМЕНТЫ СЛОЯ ИНФРАСТРУКТУРЫ: ТЕРРИТОРИАЛЬНЫЕ ЦЕНТРЫ РАЗМЕЩЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ ЦОД №1 ЦОД (Арендованный) ЦОД №2 (Резервный) ЦОД №3 (на Пражской) ЦОД Новосибирска ЦОД Омска ЦОД Красноярска ЦОД Иркутска Серверная комната на пр.Мира ЦОД (Арендованный) ЦОД для клиентов ЦОД для SaaS продуктов Регион Северо-Запад ЦОД (Основной) ЦОД Мурманска ЦОД коммерческ ий Серверное помещение Серверное помещение ПО КАЖДОМУ ЦОД’У ЗАПОЛНЯЕТСЯ ЕГО АТРИБУТИВНЫЙ СОСТАВ (ФОРМУЛЯР ЦОД’а): ПЛОЩАДЬ, МОЩНОСТЬ, ОТВЕТСТВЕННЫЙ, АДРЕС И Т.П. КАЖДАЯ ИНФОРМАЦИОННАЯ СИСТЕМА СВЯЗАНА С ОДНИМ ИЗ ЦОД’ОВ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 34. СТРАНИЦА 35 СОЧЕТАНИЕ ДВУХ ПОДХОДОВ При создании архитектуры возможно использование двух подходов: • Сверху вниз или от общего к частому. Основные аналитические методы – декомпозиция и детализация. • Снизу вверх или от частного общего. Основные аналитические методы – агрегация и обобщение. В текущий момент у заказчика превалируют: • на уровне штаб-квартиры: ToBe-проектирование сверху вниз, то есть от новых/изменяющихся целей и задач бизнеса к функциям информационных систем. • на местах (в регионах): подход снизу вверх, то есть от имеющихся систем и функций к новым возможностям для бизнеса. +7 495 922 12 40. Рудь Виктор ПРАВИЛЬНОЕ ПРОЕКТИРОВАНИЕ ЗАКЛЮЧАЕТСЯ В КОМБИНАЦИИ ДВУХ ПОДХОДОВ, А НЕ В ОДНОЗНАЧНОМ ПРЕДПОЧТЕНИИ ОДНОГО ИЗ НИХ.
- 35. СТРАНИЦА 36 ПОЧЕМУ АРХИТЕКТУРОЙ НЕ ЗАНИМАЛИСЬ РАНЕЕ? Не было и нет инструментов для такого моделирования. Не было и нет регулярной архитектурной практики. Гипертрофированная роль целевых моделей (планирование будущего) в ущерб AsIs-моделям (понимание настоящего): будущее не приходит, а настоящее постоянно усложняется заплаточными методами. Нет специалистов, способных разработать метамодель. Нет понимания как актуализировать результаты больших исследовательских работ. Сложно найти баланс между желаниями по быстрым выгодам от архитектурного проекта и необходимостью длительных, скрупулезных и трудоемких исследований текущего хаоса/порядка в компании. +7 495 922 12 40. Рудь Виктор ДЛЯ КРУПНЫХ КОМПАНИЙ ПОНИМАНИЕ НАСТОЯЩЕГО НЕ МЕНЕЕ ВАЖНО, ЧЕМ ВИДЕНИЕ БУДУЩЕГО. И ПОТОМУ НУЖНЫ СИСТЕМНЫЕ УСИЛИЯ В ОБЛАСТИ «ИНВЕНТАРИЗАЦИИ» СИСТЕМ, ФУНКЦИЙ, ИНФОПОТОКОВ, ИНТЕГРАЦИЙ.
- 36. СТРАНИЦА 37 АРХИТЕКТУРНЫЙ ПРОЕКТ: ЧИСЛО ЗАДЕЙСТВОВАННЫХ РЕСУРСОВ От управляющей компании: • по одному человеку на макрорегион (7 человек) • один человек на управляющую компанию (1 человек) • по одному специалисту от каждого проектного офиса (4 человека) • администратор системы (1 человек на 50%) От компаний холдинга: • один ответственный в каждом макрорегионе (8 человек) • специалисты по каждой системе От консультантов: Управление проектом Обучение рабочей группы Методическое руководство Разработка и поддержание метамодели Архитектор интеграций Консультант по процессным моделям Специалисты по предметным областям УК «Марк Аврелий»
- 37. СТРАНИЦА 38 24 ДОМЕНА ДЛЯ ПРОЕКТИРОВАНИЯ (ФОКУС НА 6 ПРОЦЕССАХ) MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Продажи B2B Продажи B2C Расчеты с клиентами Претензионная работа Тех.поддержка B2C Взыскание задолженности 4. Архитектура взаимодействий (интеграции систем) 1. Архитектура систем (системы и функции первого порядка) 3. Архитектура данных (сущности информационных систем и их атрибуты) 2. Архитектура функций и распределение информации по системам (бизнес-объекты и функции второго порядка) Проектирование системной архитектуры ограничено классами систем (8 функциональных классов). Моделирование процессов охватывает только процессы продаж и обслуживания клиентов. С точки зрения процессного анализа, процесс (кроме диаграммы действий) моделируется в дополнительных 4 слоях: слой обеспечивающих систем; слой функций, задействованных в системах; данные и информация в процессе; потоки данных, перемещаемые между системами в ходе процесса.
- 38. СТРАНИЦА 39 ОБЪЕМ СМОДЕЛИРОВАННОЙ ИНФОРМАЦИИ Более 1000 информационных систем (в том числе их инсталляций) Сотни-тысячи уникальных функций Тысячи интеграций Моделирование выполнено для 7 федеральных регионов. В ходе моделирования собрано, исследовано и рассортировано более 5 гигабайт документации. MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 39. СТРАНИЦА 40 РАЗДЕЛ 3. МЕТАМОДЕЛЬ Метамодель – предопределенная и ограниченная совокупность типов структурных элементов, а также их взаимосвязей, с использованием которых строится модель предметной области. MARCUS AURELIUS LTD
- 40. СТРАНИЦА 41ОБЩАЯ МЕТАМОДЕЛЬ Data/Business Object (Какие информационные объекты обрабатываются?) Application X (информационная система) Data/Business Object Data/Business Object Data/Business Object Application Function Application Function ИНФОПОТОК (Application Interaction) Application Y (информационная система) Application Interface Application Function Data/Business Object
- 41. СТРАНИЦА 42 Application Component – одна инсталляция автоматизированной информационной системы Функция системы – элемент поведения системы, отражающий определенный паттерн обработки данных или контроля за ходом бизнес-процесса Интерфейс системы – «механизм» предоставления определенного поведения системы наружу. Application Interaction – взаимодействие систем, как правило – поток данных или вызов функций. Процессы – элементы взаимоувязанных цепочек действий. Функция подразделения – предписанный подразделению вид деятельности Node – центры обработки данных Data Object – элемент представления модели данных Location – место установки или использования системы СТАНДАРТНЫЕ И ДОРАБОТАННЫЕ ЭЛЕМЕНТЫ ДЛЯ МОДЕЛИРОВАНИЯ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор СТАНДАРТНЫЕ ЭЛЕМЕНТЫ Application Module – модуль информационной системы. Группирует функции и интеграции. Application Platform – система, функции и интеграции которой лежат в основе нескольких внедрений (инстансов системы). SudFunction – функции 2-го и далее порядков. Используются для моделирования системного поведения. НОВЫЕ ЭЛЕМЕНТЫ
- 42. СТРАНИЦА 43 ПОСТРОЕНИЕ СВЯЗЕЙ: ФУНКЦИИ И ДАННЫЕ СВЯЗИ ВНУТРИ СЛОЯ АРХИТЕКТУРЫ СИСТЕМ И ДАННЫХ СВЯЗИ МЕЖДУ СЛОЯМИ
- 43. СТРАНИЦА 44 i ЭЛЕМЕНТЫ ДЛЯ ОПИСАНИЯ IT-ЛАНДШАФТА MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор 8 – количество инсталляций информационной системы Информационная система используется в архивном режиме: данные доступны только на чтение. 1 – количество инсталляций информационной системы Информационная система является мультифункциональным решением, т.е. выполняет функции, свойственные системам, относящимся к различным классам. 1 – количество инсталляций информационной системы - Для информационной системы разработан паспорт Информационная система используется сотрудниками компании на определенной территории (на дорожке которого она нанесена), но физически система установлена* вне данной территории. Характерно для централизованных систем. Информационная система в месте ее инсталляции*. Местом инсталляции может быть ЦОД или Территория. * ВАЖНО ПОНИМАТЬ: ИНВЕНТАРИЗИРУЮТСЯ НЕ САМИ СИСТЕМЫ И ИХ ИНТЕГРАЦИИ, А ИНСТАНСЫ СИСТЕМ И ИНФОПОТОКИ МЕЖДУ ИНСТАНСАМИ (ЭКЗЕМПЛЯРАМИ) СИСТЕМ.
- 44. СТРАНИЦА 45 IT-ЛАНДШАФТ: ФОРМУЛЯР ИНФОРМАЦИОННОЙ СИСТЕМЫ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Общее описание системы Общее описание системы Связи системы Вхождения системы в различные диаграммы Атрибуты системы: СУБД, Вендор, Статус и т.п.
- 45. СТРАНИЦА 46 ПРИМЕРЫ АТРИБУТОВ ФОРМУЛЯРА ИНФОРМАЦИОННОЙ СИСТЕМЫ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Название поля 1 ID системы 2 Полное наименование системы 3 Краткое имя для схем 4 Краткое описание системы 5 Место текущей физической установки ИС 6 Уровень унификации решения 7 Количество установок 8 Аналитик 9 Класс ИС 10 Целевая архитектура (признак) 11 Ответственный департамент в УК 12 Локальный разработчик ИС 13 Вендор ИС 14 Интегратор ИС Название поля 15 Язык разработки ИС или СУБД 16 Оценка имеющейся документации 17 Штат специалистов по ИС 18 Статус реализации ИС: • промышленная экслплуатация • архивная система • система на стадии внедрения • выведена из эксплуатации 19 Куда выгружается отчетность? 20 Ответственное лицо по ИС • ФИО • Телефон/Email • Подразделение ответственного лица 21 Контактное лицо по ИС • ФИО • Телефон/Email 22 Заказчик ИС • ФИО • Телефон/Email • Подразделение ответственного лица
- 46. СТРАНИЦА 47 ПОСТРОЕНИЕ СВЯЗЕЙ: ФУНКЦИИ И ИНФОПОТОКИ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор ИНФОПОТОКИ ФУНКЦИИ СИСТЕМЫ СВЯЗИ МОЖНО УСТАНАВЛИВАТЬ КАК ГРАФИЧЕСКИ, ТАК И ТАБЛИЧНО
- 47. СТРАНИЦА 48 МЕТАМОДЕЛЬ ИНТЕГРАЦИОННЫХ ВЗАИМОДЕЙСТВИЙ Приложение Х в контексте выполнения своей функции вызывает приложение Y через интерфейс, который предоставляет приложение Y. При этом возникает поток данных, логически связанный с одним из объектов информационной модели предприятия. Application YApplication X Application Function Application Interface Application Function Application Interaction (ИНФОПОТОК) Application Collaboration Application Interface Data Object MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 48. СТРАНИЦА 49 ФОРМУЛЯР ИНФОПОТОКА: ОПИСАНИЕ ИНТЕГРАЦИОННОГО ВЗАИМОДЕЙСТВИЯ ДВУХ СИСТЕМ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Название поля Тип поля 1 Номер инфопотока Текст 2 Краткое наименование инфопотока Текст 3 Полное наименование инфопотока Текст 4 Описание инфопотока или комментарии по реализации Текст 5 Активный? (используется или нет) Boolean 6 Статус описания (в работе; описание завершено; заблокировано от изменений) Список выбора 7 Ответственный аналитик Список выбора 8 Вызывающая система Ссылка 9 Вызываемая система Ссылка 10 Состав передаваемых данных или название запрошенной функции Текст 11 Релевантные информационные объекты Ссылка 12 Наименование API и метода, предоставляемого вызываемой системой Текст 13 Метод интеграции Список выбора 14 Протокол интеграции Список выбора
- 49. СТРАНИЦА 50 КАРТОЧКА ИНФОПОТОКА (ПРОДОЛЖЕНИЕ) MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Название поля Тип поля 14 Инициирующее событие в системе №1 Текст 15 Функция системы №1 (вызывающей системы), в контексте которой происходит вызов системы 2 Ссылка 16 Функция системы №2 (вызываемая система), в контексте которой происходит «прием» инфопотока или собственно вызываемая функция Текст 17 Интегратор Текст 18 Контакты интегратора Текст 19 ИТ-специалист, ответственный за интеграцию Текст 20 Документация, описывающая интеграцию Текст
- 50. СТРАНИЦА 51 КАРТОЧКА ФУНКЦИИ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Название поля Тип поля 1 Полное наименование функции Текст 2 Краткое наименование функции Текст 3 Описание функции или комментарии по функции Текст 4 Активна? (используется или нет) Boolean 5 Статус описания: - в работе - описание завершено - заблокировано от изменений Список выбора 6 Ответственный аналитик Список 7 Связь с модулем системы Ссылка 8 Связь(и) с дочерними функциями Ссылка
- 51. СТРАНИЦА 52 РАЗДЕЛ 4. ВИДЫ ДИАГРАММ Диаграммы, которые были созданы в рамках проекта, носят иллюстративный характер, либо являются ключевым артефактом проекта, так как отображают связи между объектами модели. Ряд диаграмм был определен в качестве обязательных диаграмм по каждой системе. В сущности, диаграммы – это определенного вида представления данных, так как классические представления данных в табличном виде не позволяют быстро вникнуть в моделируемой явление. MARCUS AURELIUS LTD
- 52. СТРАНИЦА 53 VIEWPOINTS - ПРЕДСТАВЛЕНИЯ МЫ ГОТОВЫ СМОДЕЛИРОВАТЬ ЛЮБУЮ ТОЧКУ ЗРЕНИЯ!
- 53. СТРАНИЦА 54 ПОСТРОЕНИЕ СВЯЗЕЙ: ФУНКЦИИ И ДАННЫЕ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор ПРИМЕР ДИАГРАММЫ, ОТРАЖАЮЩЕЙ СВЯЗЬ ПРИЛОЖЕНИЙ ПО ДАННЫМ ПРИМЕР ДИАГРАММЫ, ОТОБРАЖАЮЩЕЙ ЗАВИСИМОСТЬ ПРОЦЕССА ОТ СИСТЕМ
- 54. СТРАНИЦА 55 ПРИМЕР ДИАГРАММЫ ДАННЫХ
- 55. СТРАНИЦА 56 Регион 2Регион 1 Домен 2 Домен 1 ПРИМЕР ЛАНДШАФТНОЙ ДИАГРАММЫ СИСТЕМЫ, ПРЕДСТАВЛЕННЫЕ ПО ФУНКЦИОНАЛЬНЫМ ДОМЕНАМ И ФЕДЕРАЛЬНЫМ РЕГИОНАМ Автоматизирова нная система расчетов Личный кабинет пользователя Финансовая система Логистическая система Система приема платежей Система сопряжения с оборудованием Система расчета мощности Система CRM Учет основных средств Учет производственн ых мощностей Единая база знаний Маркетинговый портал Система автоматизации проектирования Автоматизирова нная система расчетов Личный кабинет пользователя Финансовая система Логистическая система Система приема платежей Система сопряжения с оборудованием Система расчета мощности ГИС Система CRM Учет основных средств Учет производственн ых мощностей Единая база знаний Маркетинговый портал Система автоматизации проектирования Система мониторинга сети MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 56. СТРАНИЦА 57 ИНТЕГРАЦИИ СИСТЕМЫ ДЛЯ КАЖДОЙ СИСТЕМЫ МЫ ПОКАЗЫВАЕМ, КАКОЕ ОКРУЖЕНИЕ ЕЙ ТРЕБУЕТСЯ ДЛЯ ИСПОЛНЕНИЯ ЕЕ ФУНКЦИЙ. MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Application Х Application Component Application Component Application Component Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Function Application Interface Application Interface Application Interface Application Interface Application Interface Application Interface Application Interface Application Interface Application Interface Мы, возможно, должны понимать, в рамках какой функции системы предоставляется данный интерфейс. Но это не требуется отображать на нашей диаграмме
- 57. СТРАНИЦА 58ФУНКЦИИ СИСТЕМЫ СИСТЕМА, ЕЕ МОДУЛИ, А ТАКЖЕ ИХ ФУНКЦИИ 1-ГО, 2-ГО И 3-ГО ПОРЯДКА.
- 58. СТРАНИЦА 59 ВЗАИМОСВЯЗЬ ГРУППЫ СИСТЕМ В КОНТЕКСТЕ ОДНОГО ПРОЦЕССА ДАННЫЕ ДИАГРАММЫ ИЛЛЮСТРИРУЮТ, КАКИЕ БИЗНЕС-ПРОЦЕССЫ ЗАВИСЯТ ОТ СИСТЕМЫ ИЛИ В КАКИХ БИЗНЕС- ПРОЦЕССАХ И КАКИМИ СВОИМИ ФУНКЦИЯМИ СИСТЕМА УЧАСТВУЕТ. MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Application Х Application Function Business Process SubProcess SubProcess SubProcess Application Function Application Function Business Process Business Process Application Х Application Function Business Process SubProcess SubProcess SubProcess Application Function Application Function Business Process Business Process
- 59. СТРАНИЦА 60 ПРИМЕР НЕ СТРОГОЙ ДИАГРАММЫ НЕКОТОРЫЕ ДИАГРАММЫ НЕ ЯВЛЯЮТСЯ СТАНДАРТНЫМИ ДЛЯ ПРОЕКТА И ИСПОЛЬЗУЮТСЯ ДЛЯ ИЛЛЮСТРАЦИИ СЛОЖНЫХ ПРЕДМЕТНЫХ ДОМЕНОВ ИЛИ ДЛЯ РЕШЕНИЯ ОДНОЙ ОПРЕДЕЛЕННОЙ ЗАДАЧИ, КАК ПРАВИЛО СВЯЗАННОЙ С ОПТИМИЗАЦИЕЙ. ЛЮБЫЕ ДИАГРАММЫ В QPR ЯВЛЯЮТСЯ ИНТЕРАКТИВНЫМИ.. ДИАГРАММА ВЗАИМОДЕЙСТВИЯ СИСТЕМ В ЦИКЛЕ РАСЧЕТОВ С КЛИЕНТАМИ
- 60. СТРАНИЦА 61 ЗАВИСИМОСТЬ ПРОЦЕССА ОТ СИСТЕМ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Application Component Application Function Business Process Х SubProcess SubProcess SubProcess Application Component Application Function Application Component Application Function НА КАКИЕ СИСТЕМЫ ОПИРАЕТСЯ БИЗНЕС-ПРОЦЕСС? ОТ КАКИХ СИСТЕМ ОН ЗАВИСИТ?
- 61. СТРАНИЦА 62 РАЗДЕЛ 5. ПОРЯДОК АКТУАЛИЗАЦИИ Архитектура всегда находится в квазиактуальном состоянии, так как нет возможности поддерживать модель в полном соответствии с постоянно изменяющимися реалиями бизнеса. Это понимают все и это изначально заложено в архитектурные методологии, такие, например, как TOGAF. MARCUS AURELIUS LTD
- 62. СТРАНИЦА 63 Классы операций Подразделение, обслуживающее территорию Территория Объекты данных Атрибут Класс систем ПОРЯДОК АКТУАЛИЗАЦИИ АРХИТЕКТУРЫ
- 63. СТРАНИЦА 64 ОБ АКТУАЛИЗАЦИИ И ПОДДЕРЖАНИИ АРХИТЕКТУРЫ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Все выделенные нами структурные компоненты архитектуры: системы, функции, интерфейсы, интеграции - достаточно стабильны во времени и легко подлежат периодической или даже постоянной актуализации. Оценочно для актуализации требуется ресурс в количестве 1 человек на макрорегион.
- 64. СТРАНИЦА 65 24 ДОМЕНА ДЛЯ ПРОЕКТИРОВАНИЯ – ХОРОШИЕ КАНДИДАТЫ ДЛЯ ПЛАНИРОВАНИЯ СКОУПА АКТУАЛИЗАЦИИ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Продажи B2B Продажи B2C Расчеты с клиентами Претензионная работа Тех.поддержка B2C Взыскание задолженности 4. Архитектура взаимодействий (интеграции систем) 1. Архитектура систем (системы и функции первого порядка) 3. Архитектура данных (сущности информационных систем и их атрибуты) 2. Архитектура функций и распределение информации по системам (бизнес-объекты и функции второго порядка) Актуализация может выполняться по-процессно или по слоям. Или даже в отдельном небольшом домене. Это зависит от поставленной со стороны бизнеса или ИТ задачи.
- 65. СТРАНИЦА 66 TOGAF ОБ АКТУАЛИЗАЦИИ И ПОДДЕРЖАНИИ АРХИТЕКТУРЫ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Поддержание архитектуры в актуальном состоянии – это дискретный эволюционный процесс. Актуализация архитектуры выполняется в отдельных доменах, которые каждое предприятие определяет для себя самостоятельно. Таким доменом может быть: • бизнес-процесс, • управление или департамент, бизнес-блок, • бизнес-функция, • бизнес-единица или деятельность в рамках определенной линейки продуктов, • архитектурный слой, например, модель данных или сетевая инфраструктура. Architecture Continuum Generic Architectures Specific Architectures Обобщение с целью переиспользования Адаптация под конкретную задачу ПРАВИЛЬНОЕ УПРАВЛЕНИЕ АРХИТЕКТУРОЙ – ЭТО УПРАВЛЕНИЕ ABB (ARCHITECTURE BUILDING BLOCKS) – ЗАКОНЧЕННЫЕ АРХИТЕКТУРНЫЕ ФРАГМЕНТЫ, СОВОКУПНОСТЬ КОТОРЫХ СОСТАВЛЯЕТ ВСЁ АРХИТЕКТУРУ ПРЕДПРИЯТИЯ. ОТДЕЛЬНЫЕ ABB МОГУТ УСТАРЕВАТЬ С ТОЧКИ ЗРЕНИЯ ИХ ВНУТРЕННЕГО УСТРОЙСТВА, НО ОСТАВАТЬСЯ НЕИЗМЕННЫМИ В ТОМ, КАК ОНИ ВХОДЯТ В ОБЩУЮ КОНСТРУКЦИЮ ПРЕДПРИЯТИЯ. Не всякое архитектурное описание одинаково быстро теряет свою актуальность. Это зависит от степени его обобщенности: верхнеуровневые генерализированные архитектуры более «долговечны» и стабильны во времени: Следует также отличать Architecture Continuum от Solution Continuum. Последний представляет собой набор конкретных реализаций тех или иных ABB в виде законченных развёрнутых решений (SBB – Solution Building Blocks). SBB не абстракты и четко документированы в силу их физической природы. Это лежит в основе их достаточно простой актуализации.
- 66. СТРАНИЦА 67 РАЗДЕЛ 6. ВОЗМОЖНОСТИ ИНСТРУМЕНТА Возможности программного инструмента Enterprise Architect финской компании QPR Software PLC. Отличительной особенностью продукта является интуитивная простота работы (как с VISIO) c возможностью получения интерактивных диаграмм, а также неограниченная свобода в использовании на схемах любых элементов, не предусмотренных нотацией моделирования. Это делает схемы на столько выразительными, на сколько вы умеете управлять визуальным восприятием сложных картинок высокой степени детализации. MARCUS AURELIUS LTD
- 67. СТРАНИЦА 68 ИНСТРУМЕНТАЛЬНАЯ СРЕДА МОДЕЛИРОВАНИЯ MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор ENTERPRISE ARCHITECT. QPR SOFTWARE PLC
- 68. СТРАНИЦА 69 ВОЗМОЖНОСТИ ENTERPRISE ARCHITECT Поддержка стандарта Archimate 2.0 Поддержка стандарта BPMN Возможность разработка любой (!) нотации Возможность доработки встроенных нотаций Конструирование любой метамодели Управляемые панели инструментов Возможность устанавливать связи между моделями Связывание объектов атрибутивно или графически Коллективная работа на общем сервере Локальная работа на ноутбуке с копией сервера в режиме редактирования и без связи с сервером Vbasic-образный язык разработки скриптов для автоматизации рутинный операций Поддержка TOGAF MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 69. СТРАНИЦА 70 QPR ENTERPRISE ARCHITECT QPR Enterprise Architect - среда коллективной работы с моделями: Содержит карточки всех систем Содержит карточки всех интеграций Содержит все справочники, нужные для стандартизации ввода данных Содержит все представления (отчеты) Содержит различные подложки для отображения данных Содержит интерактивные диаграммы, созданные в полной взаимосвязи с реестрами систем, функций, интеграций Содержит взаимосвязи между всеми элементами, включая возможность навигации между формулярами объектов и схемами Предоставляет единый механизм поиска артефактов моделирования: как на схемам, так и в реестрах MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор Enterprise Architect – единая интегрированная среда, в которой интегрированы: системы, функции, интерфейсы, инфопотоки, процессы, цели, задачи и т.п. зафиксированные в виде артефактов системы и иллюстрированные интерактивными диаграммами.
- 70. MARCUS AURELIUS LTD. КОНТАКТЫ ДЛЯ СВЯЗИ Рудь Виктор Директор по консалтингу ООО «МАРК АВРЕЛИЙ» http://www.consulo.ru E-mail: v.rud @consulo.ru Телефон: +7 (495) 922-12-40 Не отказывайся от помощи, особенно когда это связано с исполнением долга. Многое из того, что не удаётся сделать в одиночку, может быть легко достигнуто, если действовать сообща… Марк Аврелий MARCUS AURELIUS LTD.
- 71. WWW.MARCUS-AURELIUS.RU Рудь Виктор Геннадиевич Директор по консалтингу ООО «МАРК АВРЕЛИЙ» e-mail: v.rud @consulo.ru Телефон: +7 (495) 922-12-40 Marcus Aurelius ltd.
- 72. СТРАНИЦА 73 Управление архитектурой систем и предприятия Концептуальное проектирование Реинжиниринг процессов Дизайн информационных систем Бизнес-анализ Дизайн и поддержание автоматизированных каталогов услуг Проведение тендеров на выбор программного обеспечения Обучение по архитектурным методологиям Управление требованиями Разработка Требований, Тех.Заданий, Архитектурных решений и концепций Организационный дизайн Процессное управление Проработка KPI процессов и подразделений Управление проектом Планирование проекта и ресурсов Создание и контроль процессной архитектуры Создание и контроль функциональной архитектуры Создание и контроль информационной архитектуры Разработка учебных материалов Обучение ключевых пользователей Нормирование численности подразделений и оптимизация орг.штатной структуры Реинжиниринг процессов Подготовка процессов и функций к передаче в аутсорсинг Виды услуг компании: Виды помощи в больших проектах: ЭКСПЕРТИЗА И УСЛУГИ КОМПАНИИ «МАРК АВРЕЛИЙ» MARCUS AURELIUS LTD. +7 495 922 12 40. Рудь Виктор
- 73. СТРАНИЦА 74 КЛИЕНТЫ КОМПАНИИ «МАРК АВРЕЛИЙ» MARCUS AURELIUS LTD. СЕВЕРНЫЕ ПРИИСКИ