|
|
Итархитектура и итстратегия Тема 1 Актуальность проблематики связана с
Элементы управления и контроля Архитектуры на различных этапах ИТ-проектов Организационные структуры, связанные с управлением и контролем Архитектуры Организация работы над Архитектурой Постоянная работа над Архитектурой с организационной точки зрения ведется как бы на трех уровнях: - стратегический уровень, на котором принимаются общие решения, касающиеся принципов использования архитектуры, основных направлений ее развития, достижения соглашений в организации о целесообразности этих усилий;
- уровень внесения существенных изменений в архитектуру;
- повседневная работа над созданием документов и моделей, описывающих архитектуру, информирование подразделений организации, обучение, демонстрация и т.д.
Модель Giga Group Модель Giga Group Она обеспечивает классификацию архитектурных решений в соответствии со стратегическим позиционированием каждого решения. - Ядро архитектуры (центральная зона) – это те архитектурные решения, технологии, стандарты, которые в данный момент времени приняты организацией в качестве стратегических.
- Запретная зона (внешняя зона) определяет список технологий, продуктов, средств разработки, которые не должны использоваться внутри организации, ее департаментами, ни в каких проектах.
- Область обсуждаемых возможностей (средняя зона) находится между ядром архитектуры и запретной зоной.
Модель TOGAF Она описывает описаны два основных процесса: - формализованную проверку проекта на соответствие Архитектуре;
- оценку влияния Архитектуры на проекты.
Модель TOGAF Цели проверки на соответствие Архитектуре - уменьшение проектных рисков за счет идентификации ошибок и «узких мест» в Архитектуре разрабатываемой системы;
- использование преимуществ известных методов лучшей практики, существующих архитектурных прототипов или технологических инноваций;
- оценка технического уровня и степени готовности разрабатываемой системы для независимой оценки и доклада руководству;
- идентификация областей, где сама Архитектура (профили стандартов) может требовать модернизации.
Текущие затраты на сопровождение Архитектуры - обеспечение поддержки Архитектуры со стороны сотрудников ИТ-службы и бизнес-подразделений;
- создание, документирование и публикация информации об Архитектуре;
- проведение анализа и контроль соответствия архитектурных решений отдельных проектов;
- обучение и оценка результатов;
- подготовка планов технологического развития, связанных с новыми технологиями.
Gap-анализ (анализ несоответствий) Этот анализ является критически важным с точки зрения определения ключевых шагов и необходимых изменений в направлении целевой Архитектуры. Необходимо категоризировать идентифицированные несоответствия и собрать вместе бизнес-требования, технологические потребности, требования к информации и приложениям – для того, чтобы начать решение соответствующих проблем. При этом несоответствия могут быть связаны с вопросами культуры организации, структурными проблемами, функциональными или же процедурными вопросами. Процесс анализа на несоответствия включает следующие шаги: - идентификация различий между существующей и целевой архитектурой;
- составление списка идентифицированных несоответствий с разбивкой по категориям и составление списка требуемых изменений;
- идентификация уже имеющихся возможностей ИТ-систем, которые могут быть использованы для удовлетворения идентифицированных проблемных мест, и обновление списка несоответствий с учетом этого фактора;
- группировка идентифицированных несоответствий по типу их влияния на деятельность предприятия.
Категории несоответствий в gap-анализе | |
Структурные
|
Функциональные
|
Культурные
|
Процедурные
|
Бизнес-аспекты
| | | | |
Информация
| | | | |
Технологии
| | | | |
Приложения
| | | | |
Организационные аспекты
| | | | |
Другие категории
| | | | | - Под структурными несоответствиями понимаются несоответствия между существующим и целевым состоянием, связанные с вопросами инфраструктуры.
- Функциональные несоответствия связаны с возможностями систем по поддержке новых бизнес-процессов, которые необходимы для реализации новых бизнес-стратегий.
- Культурные несоответствия – это несоответствия между сегодняшним состоянием ИТ-департамента организации и требующимися навыками, компетенциями и структурами, которые необходимы для решения проблем.
- Процедурные несоответствия – это несоответствия между существующими и желаемыми методами управления, стратегиями сорсинга, процессами эксплуатации ИТ-сервисов и организационными процедурами.
Важность Архитектуры ИТ «Повышение способности к взаимодействию» компонент информационных систем предприятия рассматривается как главное преимущество Архитектуры, которое актуально для всех сотрудников организации. В более общем плане, информационные системы в целом приобретают расширенные способности к взаимодействию с системами поставщиков и клиентов, что, в свою очередь, способствует развитию взаимосвязей предприятия. Спасибо за внимание! Оценка зрелости архитектуры Тема 12 Методика Кросби В основе моделей оценки зрелости тех или иных процессов лежит новаторская работа Филиппа Кросби (Philip Crosby) «Quality is Free» (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством TQM (Total Quality Management), созданной В. Деммингом, Дж. Мураном и Ф. Кросби Методика Кросби Методика включает в себя пять стадий или уровней развития процессов, связанных с качеством: - неопределенность;
- пробуждение;
- осведомленность или обучение;
- мудрость;
- определенность.
Модель Кросби в отношении Архитектуры Предлагаемая модель относит зрелость Архитектуры предприятия к одному из пяти уровней: - Уровень_1'>Уровень 1. Начальный.
- Уровень 2. Повторяемый.
- Уровень 3. Определенный или регламентируемый.
- Уровень 4. Управляемый.
- Уровень 5. Оптимизирующий.
Характеристики уровней организационной зрелости
| |
Уровень
|
Основные характеристики
|
1. Начальный
|
Спонтанные информационные связи. Хаотичность, непоследовательность
|
2. Повторяемый
|
Базовые процессы. Повторяемые операции
|
3. Определенный
|
Стандартизация процессов. Интеграция, наличие процедур
|
4. Управляемый
|
Контроль качества. Использование обратной связи
|
5. Оптимизирующий
|
Постоянное развитие. Самоадаптация системы
| Принцип «достаточно хорошей» Архитектуры Для реализации этого подхода рекомендуется следовать следующим трем рекомендациям: - Быть гибким и разграничивать уровни Архитектуры. Гибкость может, в частности, достигаться за счет разделения Архитектуры на предметные области (Бизнес-архитектура, Архитектура прикладных систем и т.д.).
- Концентрация на наиболее важных частях Архитектуры. Используйте правило 80/20 при определении того, над какими частями Архитектуры работать. Концентрируйтесь на вопросах, которые действительно важны для организации.
- Создавайте Архитектуру, которая может развиваться итеративно. Основной предпосылкой должно быть то, что Архитектура будет достаточно часто изменяться.
Стратегическое окно возможностей для «достаточно хорошей» Архитектуры Источники информации для систем разработки Архитектуры предприятия Принципы работы систем поддержки процесса разработки Архитектуры Спасибо за внимание!
Федеральное государственное бюджетное образовательное учреждение высшего образования
Национальный исследовательский университет «МЭИ»
Архитектура предприятия
( бизнес-архитектура ,Модели)
Проф. Крепков ИГОРЬ Михайлович
.
.
НИУ
Понятие модели
НИУ
- Модель представляет искусственный, созданный человеком объект любой природы (умозрительный или материально реализованный), который замещает или воспроизводит исследуемый объект
- Модель - упрощенный, приближенный образ, который отражает наиболее существенные (с точки зрения цели моделирования) свойства оригинала
- Соответствие модели оригиналу называется адекватностью модели.
- Адекватность включает требования полноты и точности (правильности). Требования должны выполняться в той мере, которая достаточна для достижения цели
Языки описания моделей
Языки описания моделей: аналитические, численные, логические, теоретико-множественные, лингвистические, графические
Графические модели (схемы, диаграммы, графики, чертежи) – наглядны
Нотация — система условных обозначений (знаков) и правил их использования, принятая в конкретной методологии
Требования к нотации :
простота — простой знак предпочтительнее сложного;
наглядность — хотя бы отдаленное сходство с оригиналом;
индивидуальность — достаточное отличие от других обозначений;
однозначность — нельзя обозначать одним символом различные объекты;
определенность — четкие правила использования модели;
учет устоявшихся традиций
НИУ
Содержание модели бизнеса
НИУ
Порядок моделирования предприятия:
НИУ
Бизнес-архитектура
- 1.Дерево целей ->
- 2.Организационная модель->
- 3.Функциональная модель->
(Моделирование бизнес-процессов)
Архитектура информации
- 4.Модель потоков данных->
- 5.Модель «сущность-связь»->
- 6.Даталогическая модель->
( Логическая и физическая модель базы данных)
Методы моделирования
НИУ
1. Структурные методы
|
Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.
| | | | | |
Принципы структурного подхода:
- «разделяй и властвуй» - разбиение сложных проблем на множество меньших задач, легких для понимания и решения;
- иерархическое упорядочивание – организация составных частей проблемы в иерархические древовидные структуры.
|
Характерные черты: жесткие правила, моделирование «сверху-вниз», методология – классический системный анализ, модели данных отделены от моделей потоков
| | | | | | | | | |
Методы объектно-ориентированного моделирования
НИУ
Предназначены для создания моделей систем с целью их последующей реализации в виде объектно-ориентированных программ
| | | | | | |
Главным структурообразующим элементом является объект.
В программировании объект - это структура, объединяющая данные и процедуры.
В модели бизнеса объекты – это участники бизнес-процесса (активные объекты)
и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты. Наиболее применяема UML. UML имеет черты структурных и событийных нотаций одновременно. Моделирование производится по правилам системного анализа, но на нижних уровнях применяется событийное представление процесса. Отличительной чертой являются диаграммы классов. Удобна для разработчика.
| | | | | | |
Методология IDEF0
- Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований.
- IDEF0-модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).
Основные элементы модели:
- Функциональный блок (Activity) – преобразование (активность);
- Выходы (Output) – результат преобразования;
- Входы (Input) - объекты, которые преобразуются в Выходы;
- Управление (Control) - информация, как происходит преобразование;
- Механизм (Mechanism) – объекты, осуществляющие преобразование
НИУ
Пример модели
НИУ
Моделирование и описание бизнес-процессов в нотации BPMN СТРУКТУРА ОРГАНИЗАЦИИ
НИУ
НИУ |
|
|
Скачать 4.57 Mb.