NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие. Выбор "оптимальной" методики
Стратегическая модель архитектуры SAM
Методика Стратегическая модель архитектуры SAM (Strategic Architecture Model) является интересным инструментом анализа и документирования архитектуры предприятия и связанных с ней доменов. Краткое описание этой методики в контексте ее применения для создания бизнес-шаблонов архитектуры можно найти в [5.20], а более подробную информацию – на сайте http://www.systems-advisors.com или в [5.21]. Мы сочли необходимым включить ее в наш обзор, поскольку она содержит ряд оригинальных моментов, которые отличают ее от того, что мы встречали в остальных подходах. Кроме того, эта методика активно и успешно применяется, в частности, консультантами Microsoft во внутренних и внешних проектах и помогает в создании документов, которые передаются заказчикам и партнерам в ходе работы. Сама методика была разработана английской консалтинговой компанией Systems Advisers Ltd.
SAM использует нотацию "сфер интересов" для представления целостного набора фактов о предприятии и "отношений", которые связывают эти факты в полезные группы, что обеспечивает полезный взгляд на структуру и операции, выполняемые предприятием.
SAM можно рассматривать как некоторую надстройку над моделью архитектуры предприятия Захмана. Она предоставляет общие структуры для определения архитектуры и механизмы, позволяющие организовать и анализировать информацию об архитектуре.
SAM использует итеративный подход при создании архитектуры, сочетающий элементы разработки "сверху–вниз" и "снизу–вверх". "Сферы интересов" SAM позволяют легко систематизировать всю информацию, имеющую отношение к определенному предмету, например, информацию об организационных структурах или бизнес-процессах. Сфера может заполняться в направлении "снизу–вверх" путем сбора относящейся к предметной области информации, а на более высоких уровнях эта информация будет обобщаться. Либо же заполнение может идти в направлении "сверху–вниз" с постепенной декомпозицией на более мелкие детали.
После того как некоторая пара сфер определена с достаточной степенью детализации, элементы, составляющие эти сферы, могут быть связаны так, чтобы представить существующие в реальности связи между объектами анализа. Это обеспечивает возможность оптимизации и улучшений в различных областях деятельности предприятия.
Опыт показывает, что наибольшую важность представляют следующие сферы: цели и задачи, организация, бизнес-процессы, прикладные системы, технологии, проекты, бизнес-компоненты, данные, бизнес-функции, инфраструктура. Это отражено на рис. 9.2.
Внутри каждой области интересов сохраняется информация о какой-то определенной предметной области, что обеспечивает простоту сопровождения и извлечения этой информации. Обычно применяется одна или более иерархическая структура, которые напоминают ящик с файлами. Минимальный объем информации, относящейся к какой-либо сфере, называется элементом (member). Например, элементами сферы "Местоположение" могут быть "Головной офис", "Офис продаж в санкт-Петербурге", "Завод в Волоколамске" и т.д. Другими примерами элементов различных сфер являются:
- Конкретные подразделения, например, "Отдел продаж" в сфере "Организация".
- Конкретные бизнес-процессы, например, "Прием заказа" в сфере "Бизнес-процессы".
- Конкретные информационные объекты, такие как "Клиент" в сфере "Данные".
В принципе, наименования сфер говорят сами за себя. Отметим только, что под бизнес-компонентами понимается совокупность данных и тех бизнес-функций, которые создают, читают, обновляют и удаляют эти данные. Группировка всех функций, создающих и обновляющих одни и те же элементы данных с помощью процесса под названием "коммутативная кластеризация" позволяет определить неизбыточное количество "строительных блоков" – компонент – которые могут использоваться для построения систем и приложений, поддерживающих определенные бизнес-процессы. Компоненты являются важными конструкциями в современных подходах к разработке систем. Достаточно вспомнить про сервис-ориентированную архитектуру SOA и архитектуру MDA, основанную на моделях. Объединение (инкапсуляция) функциональности и данных позволяет на практике добиться повторного и многократного использования элементов систем и дает возможность замены одних элементов другими. Компоненты предлагают "сервисы", которые могут использоваться в совокупности с другими сервисами, предлагаемыми другими компонентами в рамках сервис-ориентированной архитектуры.
Важное замечание, отраженное на нашем рисунке, состоит в том, что можно выделить три категории сфер:
- Стабильные. Эти сферы описывают достаточно стабильные элементы бизнеса и представляют фундаментальные структуры: бизнес-функции, данные, бизнес-компоненты и инфраструктуру.
- Подвижные. Эти сферы описывают то, что предприятие делает или может делать с точки зрения бизнеса, в том числе для того чтобы обеспечить отличия от конкурентов и динамичность в своей деятельности. Сферы, которые относятся к этому разделу – организация, бизнес-процессы, прикладные системы и технологии – представляют собой области, которые организация может изменить достаточно быстро. Эти сферы могут, на самом деле, находиться в процессе постоянных изменений, для того чтобы обеспечить адекватную реакцию на экономические и рыночные условия.
- Динамичные. Это те сферы, которые задают направления бизнеса, рабочие программы, управление изменениями. Они описывают основные области, в которых работает предприятие, и усилия, которые требуются для движения в сторону достижения целей и задач посредством связанных между собой проектов.
Эта классификация позволяет, во-первых, понимать, какая часть архитектуры вашего предприятия носит достаточно стабильный характер, а какая требует постоянных изменений. Во-вторых, это помогает идентифицировать достаточно стабильные области, для которых полезна разработка архитектурных шаблонов (обсуждение шаблонов см. в "Технологическая архитектура, стандарты и шаблоны" ). Такими областями, в частности, являются бизнес-функции, данные, бизнес-компоненты и, в определенной степени, инфраструктура.