Модели описания бизнес архитектуры

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

Методика FEAF Федеральной Архитектуры США

В первую очередь при обсуждении методологий, которые изначально разрабатывались с учетом специфики государства, следует отметить методику Федеральной Архитектуры США (FEAF – Federal Enterprise Architecture Framework). Эта методика отличается высокой степенью комплексности политики, процессов и моделей, что отражает исторические традиции и уровень использования ИКТ в деятельности американского правительства.

Особенности разработки архитектурных моделей бизнес процессов в нотации IDEF0 в Business Studio

Методология FEAF рассматривается в качестве ориентира и многими европейскими странами, и Евросоюзом в целом. Оригинальные документы, описывающие методологию FEAF, представлены на сайте Офиса Управления Проектом Разработки Федеральной Архитектуры США (FEAPMO – Federal Enterprise Architecture Project Management Office) www.whitehouse.gov/omb/egov. Достаточно подробное описание методики FEAF на русском языке можно найти в книгах [9.2], [9.3], [9.4]. Здесь мы отметим только самые главные моменты.

Совет руководителей информационных служб (CIO Council) начал разработку FEAF в апреле 1998 году. В основу был положен Стратегический план деятельности CIO Council, разработанный с учетом приоритетов Закона по реформированию системы управления информационными технологиями в органах государственной власти принятого в 1996 году (Information Technology Management Reform Act или, иначе, закон Клингера-Кохена), который определял направления разработки и использования Федеральной Архитектуры для максимизации отдачи от использования ИКТ в государстве под флагом «эффективности инвестиций денег налогоплательщиков в ИТ». Этот закон определил в качестве одной из обязанностей руководителей департаментов информационных технологий государственных ведомств разработку архитектуры информационных технологий.

Офис FEAPMO дает следующее определение Федеральной Архитектуры:

«Федеральная Архитектура – это концептуальная модель описания в координированной, структурированной форме деятельности федерального правительства и государственных организаций с функциональной точки зрения, вне зависимости от организационных структур, реализующих соответствующие функции, с целью улучшения их деятельности за счет использования информационных технологий».

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

Основы бизнес-архитектуры // Демо-занятие курса «Enterprise Architect»

Важной особенностью проекта Федеральной Архитектуры США является функциональный подход к описанию архитектуры, т.е. подход со стороны бизнес-процессов, а не структуры федерального правительства и госорганов. В то же время следует отметить, что в рамках FEAF модели государственных функций приводятся только для задания контекста, т.е. в рамках FEAF не производится переопределения и детализации функций отдельных агентств. Эти справочные модели служат, по сути дела, определенными руководствами, которые обеспечивают общие архитектурные принципы при реализации межведомственных проектов, а также предоставляют всем государственным организациям единую методологию при разработке собственных архитектур.

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

FEAF состоит из следующих восьми компонент, которые кратко описаны ниже и представлены на рис. 8.1.

Рис. 8.1. Методология Федеральной Архитектуры и ее компоненты

Двигатели архитектуры (Architecture Drivers). Отражают два типа внешних стимулов или источников изменения архитектуры: бизнес-стимулы и технические стимулы (или «конструкторские»). В качестве бизнес-стимула могут выступать новое законодательство, новые инициативы Президента, бюджетные ассигнования для ускорения развития отдельных сфер, рыночные силы. В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства, а также их разнообразные комбинации.

Двигатели архитектуры являются источниками изменений для архитектуры федерального предприятия и делятся на два типа:

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

Стратегическое направление (Strategic Direction). Руководство для разработки целевой архитектуры (см. ниже), которое содержит видение, принципы, цели и объекты.

Стратегическое направление определяет разработку целевой архитектуры. Оно включает в себя видение, сжатое и стратегическое описание поставленной цели развития архитектуры на предстоящие 5 лет, принципы руководства развитием этой архитектуры, а также цели и объекты для управления процессом развития архитектуры.

Текущая архитектура (Current Architecture). Определяет архитектуру «как есть» и состоит из двух частей:

• Текущая бизнес-архитектура – определяет сегодняшние потребности с точки зрения основной деятельности государственных организаций и как они обеспечиваются существующими информационными системами. Отвечает на вопрос о том, какие имеются в распоряжении функции, процессы, ресурсы.
• Текущая архитектура информационных технологий (т.е. архитектура данных, приложений и технологическая архитектура) – отображает текущее состояние возможностей технологий по обеспечению деятельности организаций и служит объектом для дальнейших изменений.

Целевая архитектура (Target Architecture). Определяет архитектуру «как должно быть построено» и состоит также из двух частей: будущая бизнес-архитектура и будущая архитектура информационных технологий (т.е., соответственно, архитектура данных, приложений, и технологическая архитектура). Она дает представление о будущих возможностях и технологиях, которые явятся результатом соответствующих изменений.

Переходные процессы (Transitional Processes). Поддерживают процесс перехода от текущей архитектуры к целевой архитектуре. Критические переходные процессы для федерального предприятия включают планирование инвестиций в сферу ИТ, планирование изменений, управление конфигурациями, контроль и управление проектами.

Основные примеры переходных процессов включают следующие:

• планирование и принятие решения по инвестициям и ИТ – при планировании должны учитываться бюджетный план, показатель возврата инвестиций, критерий «затраты-выгоды» и другие критерии;
• контроль и анализ инвестиционного управления – для поддержки процесса контроля используется информация относительно архитектуры предприятия;
• координация сегментов – координирование процесса интеграции архитектурных сегментов в единую Федеральную архитектуру;
• исследование рынка – проведение периодического анализа рынка с целью идентификации новых или усовершенствованных технологий с большими потенциальными преимуществами для реализации функций и процессов или технологий, более эффективных по критерию производительность /стоимость;
• управление активами – управление всеми активами, которые связаны с реализацией Федеральной архитектуры;
• процессы закупок – согласование процессов закупок с архитектурой и с намеченными переходными процессами;
• управление архитектурой – координация усилий по сопровождению и управлению архитектурой.

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

• общие административные системы;
• области федеральных программ, таких как внешняя торговля или предоставление грантов;
• электронная торговля для проведения небольших закупок.

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

Каждый сегмент также характеризуется текущей и будущей архитектурой данного конкретного сегмента. Соответствующая информация и модели помещаются в базу данных (репозиторий) единой Федеральной архитектуры.

Архитектурные модели (Architectural Models). Определяют бизнес- и технологические модели, которые отражают все необходимые сегменты для полного описания архитектуры. Архитектурные модели задают бизнес-архитектуру и архитектуру информационных технологий.

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

• Бизнес-модели. Это модели, которые отражают появление бизнес-потребностей, инициированных бизнес-двигателями. Моделирование предполагает создание общего набора определений, диаграмм, а также, возможно, использование автоматизированных инструментальных средств, которые облегчают понимание бизнес-функций, применяемой информации, процессов и продуктов;
• Модели технической среды (Design Models). Модели технической среды включают модели данных, модели прикладных систем и технологические модели, которые требуются для того, чтобы поддержать реализацию бизнес-потребностей.

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

Соответственно, если говорить о том, какие представления (домены) выделяются в методике Федеральной архитектуры США, то они следующие:

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

В США ведется разработка и постоянное уточнение соответствующих взаимосвязанных так называемых Справочных (эталонных) Моделей (Reference Models) для каждой из перечисленных областей.

Иерархия Справочных Моделей в рамках Федеральной архитектуры показана на рис. 8.2. Эта иерархия включает в себя следующие модели:

Рис. 8.2. Справочные модели Федеральной архитектуры США

• Справочная модель эффективности (PRM – Performance Reference Model).
• Справочная модель описания бизнеса федеральной организации (BRM – Business Reference Model).
• Справочная модель сервисных компонент (SRM – Service Component Reference Model). Это описание компонент прикладных информационных систем, обеспечивающих реализацию государственных функций.
• Справочная модель описания данных (DRM – Data Reference Model).
• Технологическая справочная модель (TRM – Technology Reference Model).

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

Эти справочные модели являются, по сути дела, определенными руководствами, которые:

• обеспечивают общие архитектурные принципы при реализации межведомственных проектов;
• обеспечивают всем государственным организациям единую методологию при разработке собственных архитектур ИТ (Корпоративных архитектур).

Помимо самих справочных моделей, офис FEAPMO разрабатывает необходимые подробные методики по их практическому применению. Это в существенной степени перекликается с подходами, принятыми, например, в Германии и Великобритании.

• 05.06 — Опубликован стандарт SQL:2023
• 05.06 — Microsoft откажется от поддержки голосового помощника Cortana в Windows позднее в этом году
• 05.06 — Intel откроет в Сеуле лабораторию для взаимодействия с Samsung и SK hynix по вопросам памяти
• 05.06 — iOS 16 установлена на 81 % совместимых iPhone
• 05.06 — Intel назначила конференцию Innovation 2023 на 19–20 сентября
• 05.06 — Google улучшила поиск в мобильном приложении Gmail с помощью искусственного интеллекта
• 05.06 — ADATA продемонстрировала память следующего поколения: CAMM, CXL и MR-DIMM
• 05.06 — В сердце нашей галактики обнаружены сотни загадочных структур
• 31.05 — Правительство Москвы запустило площадку для совместной разработки Mos.Hub
• 31.05 — Закрылся торрент-трекер RARBG — один из самых популярных в мире с кино и сериалами
• 31.05 — Google прекратила поддержку плеера Chromecast образца 2013 года
• 31.05 — Представлен релиз Chrome 114
• 31.05 — «Джеймс Уэбб» обнаружил необычную чёрную дыру в древней галактике — она впятеро массивнее, чем должна
• 31.05 — Капитализация NVIDIA превысила $1 триллион — таких компаний всего пять
• 31.05 — Apple закроет бесплатный сервис My Photo Stream
• 31.05 — Обновление WhatsApp для Android добавит трансляцию экрана и изменит панель управления
• 31.05 — Microsoft нашла временное решение для восстановления работы камеры в Surface Pro
• 31.05 — Phison представила контроллер E31T для массовых SSD PCIe 5.0 со скоростью до 10,8 Гбайт/с
• 30.05 — SK hynix запустила производство чипов DDR5 по пятому поколению 10-нм техпроцесса
• 30.05 — В космосе одновременно оказались 17 человек — это абсолютный рекорд

Источник: citforum.ru

Модели описания бизнес архитектуры

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

Рис. 3.7.2. Состав задач инжиниринга систем управления

3.8. Функциональные сферы управления

Рис. 3.8.1. Выделение функциональных сфер управления

Функциональная специализация отражает сложившуюся в практике менеджмента типологию сфер управления (см. рис. 3.8.1). В качестве типовых функциональных сфер управления называют:
• управление финансами и экономикой;
• управление маркетингом;
• управление персоналом;
• управление основными и поддерживающими процессами;
• и др.
Некоторые сферы управления компании могут выделяться только на операционном уровне (например, управление основными бизнес-процессами).
Другие сферы управления могут выделяться как на стратегическом, так и на операционном уровнях, например, стратегический маркетинг и операционный маркетинг. Единого классификатора типовых сфер управления нет, и компании при структурировании системы управления целесообразно принять корпоративный классификатор.

Рис. 3.8.2. Выделение систем стратегического и операционного управления

3.9. Менеджмент

Рис. 3.9.1. Позиционирование менеджмента

Рис. 3.9.2. Учет присутствия человека в контуре управления

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

3.10. Сфера менеджмента

4. Корпоративная архитектура

Контент

• Развитие моделей организации – функциональные модели – > процессы и проекты – > стратегии и показатели – > интегрированные модели компаний и организаций.
• Корпоративная архитектура – общее структурное представление компании (рис. 4.0.1).
• Компоненты корпоративных архитектур – бизнес-архитектура, архитектура системы управления, архитектура информационных технологий.

Источник: thelib.ru

Аналитик и архитектура: UML-диаграммы для модели C4

Хотя профессиональные задачи системного и бизнес-аналитика отличаются от тех, которые решает ИТ-архитектор, знакомство с основными принципами описания архитектуры программной системы будет полезно всем этим специалистам. Разбираемся, зачем придумана модель C4, чем она отличается от модели 4+1 и можно ли все это описать в виде UML-диаграмм.

Что такое модель 4+1 и при чем здесь UML

С одной стороны, набором UML-диаграмм можно описать практически все аспекты программной системы, что мы рассматривали здесь и здесь. С другой стороны, UML предполагает только объектно-ориентированную парадигму, имеет строгие правила записи и ограниченный алфавит нотаций. Кроме того, некоторые аспекты, связанные с проектированием, разработкой, внедрением и эксплуатацией ПО остаются за рамками этого универсального языка моделирования. Чтобы обойти эти ограничения UML в 2006-2011 гг. архитектор ПО Саймон Брауном предложил модель описания архитектуры C4, основанную на некоторых идеях UML и ранее существовавшей модели архитектурного представления 4+1.

Название C4 обусловлено сочетанием 4-х уровней (Context, Container, Component, Code) для моделирования архитектуры, начиная с контекста программной системы до кода через контейнеры и входящие в них компоненты. В отличие от UML, модель C4 не имеет строгих правил записи для графического изображения различных аспектов моделирования программной архитектуры. Главной идей метода является принцип структурной декомпозиции системы на контейнеры и компоненты с конечным моделированием набора сущностей и связей между ними в виде диаграммы классов UML или ERD.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

24 июля, 2023

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Как уже было отмечено выше, C4 основана на модели 4+1, где комбинируются разные представления системы, важные для различных стейкхолдеров: конечные пользователи, разработчики, системные инженеры (администраторы и DevOps), а также руководители проектов. А +1 означает, что вместе все эти 4 представления (логическое, реализации, физическое и процессное) образуют еще одно – сценарное. Эта модель была предложена Филиппом Кручтеном из компании Rational еще 1995 году и, в отличие от C4, предполагает только объектно-ориентированную парадигму. Поэтому неудивительно, что в качестве иллюстраций для каждого представления программной системы автор предложил использовать именно UML.

Таким образом, представления модели 4+1 отражают практическую последовательность проектирования ПО в UML, которую можно представить в следующей таблице:

Однако, несмотря на детальное описание многих аспектов, инструментарий UML и представления модели 4+1 не охватывают некоторые важные нюансы, например, положение проектируемой системы в корпоративном ИТ-ландшафте. Дополнительным ограничением модели 4+1 является фокус на ООП и использование строгих правил UML-нотаций, что накладывает определенные требования к разработчикам и читателям диаграмм, повышая порог практического использования этого инструментария. Как С4 предлагает обойти эти ограничения, рассмотрим далее.

UML для бизнес-аналитика: основы ООП и разработка моделей

Код курса

BUML

Ближайшая дата курса

10 августа, 2023

Длительность обучения

8 ак.часов

Стоимость обучения

15 000 руб.

Что такое С4 и как ее использовать

Модель C4 описывает архитектуру программных систем, иерархически декомпозируя ее с уровня контекста до контейнеров, их компоненты и внутреннего устройства компонентов на уровне кода. Хотя C4 не навязывает формальных нотаций со строгими правилами записи для построения диаграмм как это есть в IDEF0 или UML, модель предполагает наглядные иллюстрации архитектуры системы с помощью следующих схем:

• диаграммы контекста (Context), которые являются схемами 1-го уровня абстракции и показывают контекстное окружение программной системы, т.е. ключевые ее взаимодействия с акторами – активными сущностями вне системы, которые взаимодействуют с ней, но не являются ее часть. На практике акторами являются пользователи и внешние сервисы. Суть диаграммы контекста в C4 аналогична контекстной диаграмме потоков данных DFD, которая рассматривает систему как черный ящик, куда попадают потоки данных от внешних сущностей и что они получают от системы. UML-диаграмма вариантов использования (use case) верхнего уровня тоже частично раскрывает особенности контекста, однако, она рассматривает проектируемую систему скорее как серый ящик, раскрывая основные возможности, доступные тому или иному актору.

Например, в рамках системы управления оплаты договоров на образовательные курсы, что мы рассматривали здесь и здесь, диаграмма системного контекста C4 может выглядеть так:

А DFD-диаграмма контекстного уровня будет выглядеть таким образом:

Наконец, UML-диаграмму вариантов использования (use case) верхнего уровня можно представить так:

• диаграммы контейнеров (Container) разбивают систему на взаимосвязанные контейнеры – приложения и базы/хранилища данных. Также контейнером в С4 считается файловая система, программный скрипт, бессерверная функция и прочие макро-компоненты, нужные для работы описываемой системы. Суть этой диаграммы аналогична совмещенной UML-диаграмме компонентов и развертывания. Для нашей системы диаграмма контейнеров C4 может выглядеть так:

Совмещенная UML-диаграмма развертывания для системы с классической трехзвенной архитектурой может выглядеть так:

• Диаграммы компонентов (Component): разделяют контейнеры на взаимосвязанные компоненты и отражают их связи с другими контейнерами или системами. Поскольку эта схема составляется для разработчиков, в качестве компонентов в C4 могут быть контроллеры, программные модули и пр. макро-элементы кода. В UML этот уровень может быть отображен диаграммой пакетов или компонентов.
• Диаграммы кода (Code) предоставляют дополнительные сведения о дизайне архитектурных элементов, которые могут быть сопоставлены с программным кодом. Здесь могут быть представлены UML-диаграммы классов или ERD-диаграммы, иллюстрирующие структуру базы данных.

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

Основные схемы модели C4

• компонентов (component)
• развертывания (deployment)

• пакетов (package)
• компонентов (component)

Дополнительные схемы модели C4

Источник: babok-school.ru