Этап включает в себя семь шагов, цели, задачи и основные результаты которых описаны далее.
Назначение первого шага состоит в формальном определении области и целей планирования архитектуры для понимания участниками проекта того, что будет достигнуто. К его результатам относятся перечень согласованных и утвержденных целей, а также список причастных к проекту подразделений предприятия.
Целью второго шага является исследование предприятия, системных входов/выходов и вариантов на основании встреч с менеджментом. Результатами являются согласованное и утвержденное видение предприятия, а также политическая поддержка менеджмента.
Основными задачами шага являются:
Целью третьего шага является адаптация методологии планирования и создание руководства по методологии. Основными задачами шага являются:
Целью четвертого шага является наведение порядка с компьютерными ресурсами и оценка инструментария создания ЕА. Основными задачами шага являются:
Цель пятого шага — создание проектной команды. Основными задачами шага являются:
Цели шестого и седьмого шагов — подготовка рабочего плана и его презентация и утверждение. Основные задачи этих шагов традиционны, а их рассмотрение выходит за рамки статьи. В результате должен быть сформирован рабочий план и утвержден бюджет выполнения работ.
Целью бизнес-моделирования является обеспечение полной и исчерпывающей базой знаний всех участников проекта для ее использования при определении архитектуры и плана ее реализации.
Бизнес-моделирование осуществляется в два этапа-построение предварительной бизнес-модели, за которым следует построение полной бизнес-модели.
Предварительная бизнес-модель идентифицирует функции, дает их описания и идентифицирует организационные единицы — исполнителей функций. По оценкам ряда экспертов этап требует 25-30% всех трудозатрат на моделирование, он осуществляется в три шага.
Первый шаг — документирование организационной структуры предприятия — в качестве результатов получают обновленные организационные схемы, перечень ролей и мест их выполнения, оценку количества сотрудников по ролям.
Основными задачами шага являются:
Второй шаг — определение структуры бизнес-модели (идентификации и определения бизнес-функций) — в качестве результатов получают определенные функции, каждая из которых: имеет имя, имеет краткое описание или декомпозирована на подфункции, является результатом работы, по крайней мере, одной организационной единицы.
Основными задачами шага являются:
Целью третьего шага является документирование бизнес-модели и ее распространение для верификации. Основными задачами шага являются:
Этап включает в себя следующие три шага:
При планировании интервью осуществляется формирование списка интервьюируемых (с датами и временем проведения) и его согласование, распределение интервьюирующих по деятельностям и бизнес-процессам (функциональным направлениям), подготовка инструкции для конкретных участников (задачи и цели, кто, когда, где, какие вопросы и т. д.), а также, при необходимости, корректировка плана создания ЕА. Подготовка интервью включает разработку форм для управления процессом интервьюирования и фиксации результатов (прежде всего, для определения функций и информационных источников). Главной целью собственно интервьюирования является выявление необходимых данных по бизнес-модели.
На следующих шагах осуществляется обработка результатов интервью, построение детальной модели, ее анализ, формирование пакета отчетов и проведение презентации.
Целью этапа является документирование всех используемых на предприятии системных и технологических платформ, т. е. создание так называемого каталога информационных ресурсов IRC (Information Resource Catalog), по-другому — системной энциклопедии, являющейся высокоуровневым объектом, а не детальным словарем данных.
Целью первого шага является определение видов данных для IRC и проектирование форм для сбора данных.
Основные задачи шага включают:
Целью второго шага является сбор данных для IRC и их ввод (заполнение форм), а также сопоставление приложений и функций. Основные задачи шага включают:
Цель третьего шага состоит в интегрировании и верификации информации по текущим приложениям и технологическим платформам, разработке потоковых диаграмм по каждой системе. Основными его результатами являются верифицированный IRC и пакет отчетов по IRC, а также предложения по его улучшению на основе проведенных обсуждений.
На четвертом шаге осуществляется подготовка к администрированию и сопровождению IRC для его поддержки в актуальном состоянии. Здесь разрабатывается регламент поддержки, политики и процедуры сопровождения IRC, назначается ответственный по его сопровождению.
На этом этапе идентифицируются и определяются основные разновидности данных, поддерживающих бизнес-функции. Архитектура данных представляется с помощью ER-модели и состоит из сущностей данных, каждая из которых имеет атрибуты и отношения с другими сущностями.
Этап содержит четыре шага:
Целью первого шага является идентификация всех потенциальных сущностей, необходимых для поддержки бизнеса. Здесь осуществляется распределение бизнес-модели по членам команды (в разрезе деятельностей и бизнес-процессов), подготовка каждым из участников списка кандидатов в сущности, формирование общего списка кандидатов.
Целью второго шага является создание стандартного определения и описания каждой сущности, обеспечение графической иллюстрации их взаимодействий. Здесь сущности определяются и документируются, осуществляется построение ER-модели, производится сопоставление файлов и БД из IRC с сущностями.
Целью третьего шага является сопоставление сущностей с бизнес-функциями и приложениями, результатами которого являются матрица сущности-функции и матрица сущности-приложения. При этом для каждой функции нижнего уровня детализации идентифицируется вид каждой из затрагиваемых ей сущностей (создается, изменяется, используется), а приложения сопоставляются с сущностями по входам, выходам, файлам и БД.
Целью четвертого шага является подготовка, распространение и анализ отчета по архитектуре данных.
На этом этапе определяются основные виды приложений, необходимых для управления данными и поддержки бизнес-функций. Архитектура приложений не является ни системным проектом, ни детальными требованиями к системам. Она только определяет, какие приложения будут управлять данными, и снабжает соответствующей информацией исполнителей бизнес-функций.
Целью первого шага является идентификация каждого из возможных приложений и формирование их списка, при этом особое внимание уделяется приложениям, которые могут улучшить бизнес или обеспечить конкурентные преимущества.
Цель второго шага — снабдить каждое приложение стандартным описанием (определением) и построить графическую схему архитектуры приложений. Основными задачами шага являются:
Целью третьего шага является идентификация бизнес-функций, поддерживаемых или выполняемых приложениями. Здесь для каждого приложения формируется матрица приложения-функции, а также перечень функций, не поддерживаемых ни одним приложением (с объяснением причин), а также матрица приложения-организационные единицы.
Целью четвертого шага является определение соответствия архитектуры приложений и существующими на предприятии приложениями. Здесь осуществляется сопоставление каждого приложения из архитектуры приложений и существующих систем, определенных в IRC, а также контроль полноты сопоставления (каждое существующее приложение из IRC должно быть соотнесено по крайней мере с одним из архитектурных приложений), строится таблица соответствий архитектуры приложений и существующих приложений.
На пятом шаге производится подготовка, распространение и анализ отчета по архитектуре приложений.
Этот этап определяет основные виды технологий, необходимых для обеспечения окружения приложений, управляющих данными. Техническая архитектура не является ни проектом сетевого оборудования и ПО, ни детальными требованиями к ним. Она только определяет виды технических платформ, поддерживающих бизнес.
Основными шагами этапа являются:
Целью первого шага является формулирование общих принципов для технических платформ и идентификация потенциальных кандидатов в платформы.
Цель второго шага — на основании сформулированных выше принципов определить стратегию распределения приложений и данных, технические платформы. Его основными результатами является распределение данных и приложений, конфигурация технических платформ, оценка концептуальной архитектуры.
Основными задачами шага являются:
Цель третьего шага — обоснование технологических платформ путем их соотнесения с использующими бизнес-функциями, формирование таблицы платформы-приложения, таблицы платформы-бизнес-функции.
На четвертом шаге производится подготовка, распространение и анализ отчета по технической архитектуре.
Этап включает следующие основные шаги:
Целью первого шага является установка приоритетов и формирование последовательности реализации приложений (например, приложения, порождающие данные, должны быть реализованы перед реализацией приложений, использующих эти данные). Его основными результатами служат: матрица приложение-сущности данных, список упорядоченных по приоритетам приложений, план модификации и/или замены существующих систем, группировка приложений в проекты, последовательность реализации технологии. Основными задачами этого шага являются:
Остальные шаги этапа традиционны для задачи планирования и здесь не рассматриваются.
На этом этапе осуществляется подготовка окончательного отчета по ЕА, подготовка и проведение презентации.
Основными шагами этапа являются:
Все эти шаги являются достаточно традиционными и не представляют интереса в рамках настоящей статьи.
Собрана на сайте Университета Карнеги - Меллона .
В настоящее время существует сильная тенденция рассматривать архитектурное и неархитектурное проектирование как различные виды деятельности; делаются попытки определить их как отдельные практики, однако эти виды проектирования в значительной мере «переплетены». Архитектурные решения в сравнении с обычными проектными решениями рассматриваются как более абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии и на наиболее высокоуровневые структуры системы :272 .
Другие определения архитектуры системы
1 / 5
✪ System Software Tutorials | Part 02 - SIC Machine Architecture | By Vikash Mehta
✪ Открытый лекторий МИЭТ - Архитектура предприятий
✪ System Architecture: Strategy and Product Development For Complex Systems
✪ 4. System Architecture and Concept Generation
По мере роста сложности решаемых задач возникла необходимость структурирования систем. Однако практики нашли термин «структура» недостаточным для описания всех аспектов системы :272 .
Рехтин поясняет термин архитектура системы следующим образом:
Суть создания архитектуры - структурирование. Структурирование может означать превращение формы в функцию , извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель :223-224 .
Термины «архитектура» и «архитектурное проектирование» уже используются в течение приблизительно 30 лет, особенно интенсивно в программной инженерии и таких проблемных областях как ракетно-космическая отрасль :272 .
Для более подробного описания принципов построения архитектуры стандарт ISO/IEC/IEEE 42010-2011 вводит следующие понятия :2 .
Свод знаний по системной инженерии (SEBoK) делит архитектуру на логическую и физическую :269 .
Логическая архитектура поддерживает функционирование системы на протяжении всего её жизненного цикла на логическом уровне. Она состоит из набора связанных технических концепций и принципов. Логическая архитектура представляется с помощью методов, соответствующих тематическим группам описаний, и как минимум, включает в себя функциональную архитектуру, поведенческую архитектуру и временную архитектуру.
Функциональная архитектура . Функциональная архитектура представляет собой набор функций и их подфункций, определяющих преобразования, осуществляемые системой при выполнении своего назначения.
Поведенческая архитектура . Поведенческая архитектура - соглашение о функциях и их подфункциях, а также интерфейсах (входы и выходы), которые определяют последовательность выполнения, условия для управления или потока данных, уровень производительности, необходимый для удовлетворения системных требований. Поведенческая архитектура может быть описана как совокупность взаимосвязанных сценариев, функций и/или эксплуатационных режимов.
Временная архитектура . Временная архитектура является классификацией функций системы, которая получена в соответствии с уровнем частоты её исполнения. Временная архитектура включает в себя определение синхронных и асинхронных аспектов функций. Мониторинг решений, который происходит внутри системы, следует той же временной классификации :287 .
Цель проектирования физической архитектуры заключается в создании физического, конкретного решения, которое согласовано с логической архитектурой и удовлетворяет установленным системным требованиям.
После того, как логическая архитектура определена, должны быть идентифицированы конкретные физические элементы, которые поддерживают функциональные, поведенческие, и временные свойства, а также ожидаемые свойства системы, полученные из нефункциональных требований к системе.
Физическая архитектура является систематизацией физических элементов (элементов системы и физических интерфейсов), которые реализуют спроектированные решения для продукта, услуги или предприятия. Она предназначена для удовлетворения требований к системе и элементам логической архитектуры и реализуется через технологические элементы системы. Системные требования распределяются как на логическую, так и физическую архитектуру. Глобальная архитектура системы оценивается с помощью системного анализа и, после выполнения всех требований, становится основой для реализации системы :296 .
Архитектура может быть зафиксирована с помощью полного архитектурного описания (АО) (см. рисунок). Стандарт ISO/IEC/IEEE 42010-2011 предписывает различать концептуальную архитектуру системы и одно из описаний данной архитектуры, являющееся конкретным продуктом или артефактом.
В сложных системах АО может разрабатываться не только для системы в целом, но и для компонентов системы. Два разных концептуальных АО могут включать группы описаний, которые будут соответствовать одному и тому же методу описания. Хотя системы, описываемые данными двумя группами описаний, будут соотноситься как целое и часть, это не пример множества групп описаний, соответствующих одному методу. Эти АО считаются отдельными, даже хотя они связаны через системы, которые они описывают :3 .
Концептуальный подход определяет термины и понятия, относящиеся к содержанию и применению АО. На рисунке изображены основные понятия и их взаимосвязи. Все понятия определены в контексте архитектуры определенной системы и соответствующего архитектурного описания. Не нужно предполагать, что у системы существует лишь одна архитектура или что эта архитектура изображается лишь одним архитектурным описанием.
На рисунке прямоугольники изображают классы сущностей.
Линии, соединяющие прямоугольники, изображают связи между сущностями. Связь включает две роли (по одной в каждом направлении). Каждая роль может по желанию быть именована меткой. Роль, направленная от A к B, [помечена] ближе к B, и наоборот. Например, роли между «системой» и «средой» могут читаться: «„система“ живёт в „среде“» и «„среда“ влияет на „систему“». На рисунке роли обладают арностью 1:1, если не указано иное. Роль может обладать множественной арностью, например, роль, обозначенная как «1..*», применяется для обозначения многих, как в связях «один ко многим» или «многие к одному». Ромб (на конце линии связи) обозначает отношение части целого. Например, «группы описаний» являются частью «архитектурного описания». Эта нотация заимствована из UML.
Рассмотрим каждое составляющее концептуальной схемы подробнее. В контексте рассматриваемой схемы система распространяется на отдельные прикладные программные средства, системы в традиционном смысле, подсистемы, системы систем, продукты, семейства продукции, организации в целом и другие интересующие совокупности.
Система обитает в некоторой среде. Среда некоторой системы может влиять на данную систему. Её среда, или контекст, определяет обстановку и обстоятельства разработки, эксплуатации, политических и иных влияний на данную систему. Такая среда может включать другие системы, взаимодействующие с целевой системой, как напрямую через интерфейсы, так и косвенно иными путями. Такая среда определяет границы, определяющие предмет целевой системы по отношению к другим системам.
У каждой системы есть один или более стейкхолдеров . Каждый стейкхолдер обычно принимает участие в системе, или имеет интересы к данной системе. Интересы предполагают учёт таких аспектов системы как производительность, надежность, безопасность, распределённость и способность к эволюции.
Любая система существует для реализации в своей среде одной или более миссий.
В концептуальном подходе архитектурное описание организовано как одна или более архитектурных групп описаний.
Архитектурное описание выбирает для применения один или более подходящих методов описания. Выбор методов описания обычно основывается на соображениях и интересах заинтересованных сторон, которым адресовано это АО. Определение метода описания может возникать совместно с АО, а может быть определено отдельно. Метод описания, определенный отдельно от АО называется библиотечным методом описания.
Группа описаний может состоять из одного или более архитектурных описаний. Каждое такое архитектурное описание разрабатывается с применением установленных соответствующим ему методов архитектурного описания. Архитектурное описание может входить более чем в одну группу описаний :4-6 .
Существует три типа группы описаний: функциональные, логические и физические. Каждая из групп предназначена для описания собственных точек зрения и соответствующего им уровня сложности :224 .
Данная группа обеспечивает представление с точки зрения пользователей или операторов, которое включает продукты, относящиеся к фазам, сценариям и потокам задач операционной системы. Информационный поток может быть рассмотрен с пользовательского ракурса, также описываются и пользовательские интерфейсы. Примером продуктов, которые могут быть включены в это описание, будут функциональные данные или графики, сценарное описание (включая использование кейсов), блок-схемы задач, организационные диаграммы и схемы информационных потоков :224 .
Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть блочные диаграммы функциональных потоков
Термин архитектура все чаще используется вне традиционного строительного контекста, и уже сейчас можно встретить много определений архитектуры (в контексте систем) и архитектуры систем, например:
"Архитектура системы: единая фундаментальная структура системы, описанная в терминах поведения, ограничений, процессов, интерфейсов и элементов системы".
[базовое определение, одобренное INCOSE Systems Architecture Working Group на конференции INCOSE 1996 в Бостоне (Массачусетс) 8 июля 1996 года]"Архитектура системы описывает основные физические свойства, стиль, структуру, взаимодействия и предназначение системы".
[Process for System Architecture and Requirements Engineering , Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]"Архитектура - это набор концепций и правил, характеризующих структуру, семантическое поведение и взаимосвязь между компонентами системы; план конструирования чего-либо. В состав архитектуры входят элементы, образующие конструкцию, отношения между ними, ограничения на эти отношения, описание отдельных компонентов конструкции, а также описание конструкции в целом".
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations, as the source]"Архитектура - это структура компонентов программы (системы), взаимосвязей между ними и принципов их разработки и эволюции во времени".
Архитектура - это "структура компонентов, взаимосвязей между ними и принципов их разработки и эволюции о времени".
Хотя эти определения оперируют различными терминами и охватывают различные наборы аспектов, они во многом пересекаются. Все определения сходятся в том, что архитектура описывает следующие компоненты:
Для полного описания всех этих аспектов нужен богатый и потенциально сложный набор данных, однако необходимо помнить о том, что разные заинтересованные лица могут видеть и понимать эти аспекты по-разному. Концепция точек наблюдения позволяет создать несколько срезов архитектуры для того, чтобы показывать заинтересованным лицам только те аспекты, которые нужны им для эффективного участия в проекте. Кроме того, можно рассматривать систему в различных разрешениях - от низкого разрешения, соответствующего высокому уровню абстракции до высокого разрешения, при котором видны конкретные спецификации (компонентов и т.п.) для реализации.
Точка наблюдения (в контексты системы) - это "форма абстракции, которая достигается с помощью определенного набора архитектурных концепций и правил структурирования для того, чтобы сфокусироваться на определенных аспектах системы" . В следующей таблице приведены примеры точек наблюдения для различных аспектов системы. Эти точки наблюдения соответствуют стандарту ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview.
Точка наблюдения | Аспект | Сфера |
Исполнитель | Исполнителя интересуют роли и сферы ответственности организации и сотрудников (и установленные для них правила). | Деятельность исполнителей, взаимодействие пользователей с системой. Человеческий фактор и производительность труда. |
Информация | Виды информации, обрабатываемой системой, и ограничения на использование и интерпретацию этой информации. |
Целостность информации, ограничения на объем. Доступность и актуальность информации. |
Логика | Декомпозиция системы на набор подсистем, взаимодействующих через интерфейсы и обеспечивающих выполнение функций системы. |
Поведение системы отвечает требованиям. Система поддерживает расширение, адаптацию, обслуживание. Активы допускают повторное использование. |
Комплектация и физические характеристики | Инфраструктура, необходимая для обеспечения нормальной работоспособности системы. | Соответствие физических характеристик системы предъявляемым к ней функциональным и нефункциональным требованиям. |
Процесс | Параллелизм, расширяемость, производительность, пропускная способность, надежность. | Соответствие системы требованиям к времени отклика, пропускной способности и отказоустойчивости. |
Общие точки наблюдения.
Это одни из самых распространенных точек наблюдения для систем, ориентированных на программное обеспечение. Для многих систем также требуются дополнительные точки наблюдения, характерные для их предметных областей. Примерами таких предметных областей могут служить безопасность, защита и механическая организация системы. Каждая точка наблюдения охватывает определенный набор характеристик, которые должны быть учтены при разработке архитектуры и проектировании системы. Если архитектура системы во многом зависит от потребностей или точек зрения отдельных заинтересованных лиц или экспертов, целесообразно создать специальные точки наблюдения для них.
Очень важно включить в группу разработчиков архитектуры специалистов с опытом работы с различными точками наблюдения. Например, в группу можно включить аналитиков и пользователей, отвечающих за точку наблюдения исполнителей; архитекторов, отвечающих за точку наблюдения логики продукта; инженеров, которые заинтересованы в физической точка наблюдения; а также экспертов по точкам наблюдения конкретной предметной области.
Помимо точек наблюдения, в архитектуре системы необходимо создать уровни спецификаций. По мере разработки архитектура становится все менее общей и все более детализированной. В RUP различают четыре уровня архитектуры, перечисленные в следующей таблице.
Архитектурные уровни RUP
Проходя через эти уровни, проект системы превращается из абстрактной модели в конкретный план реализации. В модели контекста описываются все внешние элементы (субъекты), взаимодействующие с системой. Эти субъекты могут быть внешними или внутренними по отношению к организации, в которой развертывается система. В обоих случаях субъектами могут быть физические исполнители и другие системы. На уровне анализа разделы системы еще не привязаны к конкретным исполнителям, программному и аппаратному обеспечению. Вместо этого они отражают подходы к распределению функционального наполнения системы по отдельным компонентам. На уровне проектирования происходит выбор типов аппаратного и программного обеспечения и ролей исполнителей. На уровне реализации принимаются решения относительно конкретных видов программного и аппаратного обеспечения, которые будут применяться для реализации системы. Например, на уровне проекта может быть установлено, что потребуется сервер данных. На уровне реализации происходит выбор конкретной платформы и системы управления базой данных.
Модель - это представление системы с определенного ракурса. Как правило, для системы создается несколько моделей, поскольку как на разработку, так и на эксплуатацию системы можно взглянуть с различных точек зрения. Модели могут создаваться на различных уровнях абстракции - как на сравнительно общих, на которых скрыты, или инкапсулированы, детали реализации, так и на сравнительно детальных, на которых отражены подробные характеристики системы.
Точка наблюдения , как следует из самого названия, это определенная "позиция", с которой наблюдатель видит определенные аспекты или компоненты системы. Для формирования точек наблюдения применяются фильтры, представляющие собой наборы концепций и правил. Как правило, для понимания системы недостаточно изучить модели существующих систем или систем, которые будут созданы в будущем.
Представления - это проекции моделей, в которые входят элементы, значимые для тех или иных точек наблюдения. Обычно для иллюстрации этих проекций применяются диаграммы .
Пересечения точек наблюдения и уровней абстракции содержат представления одной или нескольких моделей, значимых для соответствующих точек наблюдения на соответствующих уровнях абстракции.
Архитектуру системы можно представить в виде набора моделей (и соответствующих диаграмм), характеризующих архитектуру с различных уровней и точек наблюдения. Как показано в следующей таблице, модели и диаграммы существуют не для всех сочетаний точек наблюдения и уровней абстракции. На уровне реализации одна модель охватывает реализацию как аппаратного, так и программного обеспечения для всех конфигураций системы.
Уровень модели | Точки наблюдения | ||||
Исполнитель | Логика | Информация | Комплектация и физические характеристики | Процесс | |
Контекст | Организационное представление UML | Диаграмма контекста системы | Представление данных организации | Представление локальности организации | Представление бизнес-процессов |
Анализ | Общее представление исполнителей | Представление подсистем | Представление данных системы | Представление локальности системы | Представление процессов системы |
Эскиз | Представление исполнителей |
Представления классов подсистем
Представления компонентов программного обеспечения |
Схема данных системы | Представление узлов дескрипторов | Подробное представление процессов |
Реализация | Инструкции и спецификации ролей исполнителей | Конфигурации: диаграммы развертывания с компонентами программного и аппаратного обеспечения системы. |
Многие представления из числа перечисленных в таблице построены на основе стандартных моделей UML. Например, на уровне анализа точки наблюдения логики система представлена в виде множества взаимодействующих подсистем, обеспечивающих выполнение требований пользователей. Подсистемы в данном случае используются в той же роли, что в стандарте UML. Эти подсистемы, в свою очередь, состоят из подсистем или (в конечном итоге) классов. Уровень проекта точки наблюдения логики соответствует подробному представлению модели классов. Модель процессов - это также стандартная модель классов UML, в которой основное внимание уделяется активным классам системы. В точки наблюдения определенных предметных областей также входят представления рабочих продуктов для одного или нескольких уровней. Набор рабочих продуктов проекта в данной среде должен представлять собой вариант разработки проекта.
Системный архитектор по-другому называется Основной обязанностью является проектирование архитектуры программного обеспечения. Сотрудник принимает ключевые решения, касающиеся устройства системы и технического интерфейса.
Это частный случай проектирования программного обеспечения.
Системный архитектор - новая позиция, которая появилась в России незадолго до 2008 года. Чтобы стать профессиональным архитектором и проектировать не дома, а ИТ-систему, необходимо понять, чем такой сотрудник занимается.
Обязанности системного архитектора заключаются в формировании итогового всей организации в деталях и в общем результате. Ключевая цель заключается в обеспечении решения задач бизнеса путем решений в информационных технологиях. При этом формирование решения - не финальный этап, контроль реализации также осуществляется архитектором.
Обязанности, которые выполняет системный архитектор, разноплановые и многогранные.
Архитектор осуществляет:
В обязанности также входит сама разработка проекта.
Среди обязательных пунктов:
Системный архитектор, как и любой другой сотрудник большой компании, занимается работой с разнообразной документацией. Ему необходимо разрабатывать, а затем контролировать оформление и согласовывать необходимые проектные, рабочие, а также Также системный архитектор разрабатывает проектную и по ПО, подготавливает отчетность, акты завершения работ и прочие документы, сопровождающие проект.
Подается отчетность согласно установленным срокам, которые оговариваются заранее, на этапе запуска проекта.
Какие обязанности может выполнять, а какие нет? Такой вопрос не возникает, так как в должностной инструкции прописаны не только права и должностные обязанности, но и отвественность, которую будет нести сотрудник.
За любое нарушение ответственность возлагается ровно в том объеме, который предполагается действующими правилами и положениями компании, заключенным договором, а также действующим законодательством Российской Федерации.
Такой сотрудник нужен далеко не каждой компании. Его навыки будут полезны там, где есть уже готовая разветвленная сеть, которой нужно придать отлаженный и структурированный вид. В маленьких компаниях, где сеть не так масштабна, его функции может выполнять продвинутый программист, проектный менеджер или другой ИТ-специалист.
Как стать системным архитектором? Для этого обязателен опыт работы в сфере программирования. На практике архитектор - это следующая ступень развития для ведущего/главного инженера, который не хочет расставаться с практической частью своей работы.
Какие обязанности системный архитектор будет выполнять, напрямую зависит от предыдущего опыта.
Системный архитектор обучение проходит не только в университете. Повышение квалификации - постоянный процесс, без которого навыки, необходимые для успешного выполнения функциональных обязанностей, не будут выработаны.
Получив степень в ИТ в любом высшем учебном заведении, архитекторы посещают курсу программирования, разработки, внедрения новых решений в системы и моделирования самих систем.
Данная позиция - довольно редко встречается даже среди специалистов узкой сферы интернет-технологий. Исходя из этого, оплата труда начинается от 70 000 р. в регионах, а крупных городах, таких как Екатеринбург, Санкт-Петербург, Москва, стартует от 130 000 р.
Должностная инструкция системного архитектора связана с выполнением работ, которые напрямую влияют на эффективность компании, а также рост ее прибыли. Чтобы сотрудник не приносил убытки и качественно справлялся с задачами, к нему предъявляется ряд требований:
Стоит отметить, что даже для специалиста без опыта работы заработные платы в Москве - от 80 000 р.
Многочисленные исследования, проводимые разнообразными карьерными порталами, выяснили, что:
В современных условиях особенно важно постоянно и правильно согласовывать ИТ-аспекты устройства современного автоматизированного предприятия с актуальными бизнес-аспектами...
В современных условиях особенно важно постоянно и правильно согласовывать ИТ-аспекты устройства современного автоматизированного предприятия с актуальными бизнес-аспектами. Делать это надо начиная с определения бизнес-архитектуры предприятия и согласованной с ней разработки системной архитектуры (ИТ-архитектуры). В предлагаемой статье автор делится практическим опытом разработки системных архитектур крупных банков и дает конкретные советы, как это можно делать - в том числе для предприятий иных отраслей.
Я - географ, а не путешественник. Мне ужасно не хватает путешественников. Ведь не географы ведут счет городам, рекам, горам, морям, океанам и пустыням. Географ - слишком важное лицо, ему некогда разгуливать. Он не выходит из своего кабинета. Но он принимает у себя путешественников и записывает их рассказы.
Антуан де Сент-Экзюпери. «Маленький принц». Глава 15. Географ
Известно, что бизнес любой современной компании все больше и больше становится зависим от информационных технологий. Развитие отдельных направлений бизнеса, например развитие «карточного бизнеса» в банках, стало возможным исключительно благодаря появлению современных ИТ. Конечно, это справедливо и для предприятий других отраслей. Потому можно надеяться, что излагаемый опыт без значительных усилий по адаптации может быть использован в бизнесе любой другой, небанковской компании.
Особенности сегодняшнего уровня развития банковских информационных технологий заключается в том, что во многих банках, которые смогли сохранить свой бизнес после кризиса 1998 года и сегодня продолжают его активно развивать и наращивать, высокотехнологичные банковские решения внедряются на фоне продолжающейся эксплуатации программных систем и комплексов предыдущих поколений, зачастую морально устаревших. С другой стороны, остановка банковского бизнеса даже на несколько часов, тем более остановка на один или несколько дней для вывода из эксплуатации устаревшего программного обеспечения и ввода в эксплуатацию нового, в большинстве случаев будет равносильна утрате бизнеса. В этой ситуации в каждый момент времени необходимо иметь четкое представление о текущем статусе всех внедряемых и эксплуатируемых информационных систем, а также не менее четкое понимание их дальнейшего развития с учетом перспектив развития банка, его архитектуры как архитектуры предприятия . (В англоязычной литературе - методиках, статьях, стандартах - этому соответствует термин enterprise architecture .)
Следует отметить, что архитектура предприятия существует независимо как от нашего сознания, так и от размера этого предприятия - будь то глобальная корпорация, небольшой завод, малое торговое предприятие и т. п. У малого предприятия архитектура есть так же, как и у крупного, при этом они не слишком сильно различаются по составу компонентов. Однако одни руководители это понимают и могут себе позволить уделять внимание всем аспектам устройства своего же предприятия (это, как правило, руководители крупных компаний), а другие - нет. Иное дело, что у малого предприятия могут быть всего два-три продукта, миссия и стратегия в явной форме не зафиксированы (эта беда, кстати, встречается часто и в крупных компаниях), количество сотрудников составляет 30 человек и в производстве используется два компьютера с MS Word 97. Но и в таком случае это все и составляет архитектуру данного предприятия.
В статье представлен достаточно развернутый и одновременно прагматичный подход к организации работ по анализу архитектуры предприятия в целом и планированию системной архитектуры, в том числе к ее документированию. Основными целями документирования знаний о бизнесе (разработки архитектуры предприятия) являются обеспечение сохранности инвестиций в бизнес и прозрачности бизнеса на всех уровнях.
Прозрачность бизнеса начинается с прозрачности понимания архитектуры предприятия, с четкого разделения ее на три взаимозависимых уровня: стратегический уровень, уровень бизнес-архитектуры, уровень системной архитектуры. Системная архитектура определяется бизнес-архитектурой, и ее проектирование может осуществляться только на основании бизнес-архитектуры, которая в свою очередь зависит от стратегии предприятия. Этот подход позволяет, на наш взгляд, не только правильно организовать сами работы и произвести корректное разделение функций и ответственности бизнес-архитектора («бизнес-девелопера»), отвечающего за развитие бизнеса, то есть бизнес-архитектуры предприятия, и системного архитектора, но и, самое главное, выстраивать сбалансированную архитектуру предприятия, адекватно соответствующую его миссии и стратегии.
В начале статьи приведены основные определения. Затем рассмотрен состав и содержание системной архитектуры, проанализированы взаимосвязи сущностей бизнес-архитектуры и системной архитектуры. Достаточно детально рассмотрены фазы и участники жизненного цикла системной архитектуры, в частности функции участников. Наконец, в сокращенном виде представлена структура знаний, лежащих в основе системной архитектуры, и сделаны заключительные выводы.
Архитектура предприятия - это наиболее общее и всестороннее представление предприятия, в данном случае - банка, как хозяйствующего субъекта, имеющего краткосрочные и долгосрочные цели ведения своей основной деятельности, определенные миссией на региональном и мировом, в нашем случае - финансово-кредитном рынке, и стратегией развития, внешние и внутренние ресурсы, необходимые для выполнения миссии и достижения поставленных целей, а также сложившиеся правила ведения основной деятельности (бизнеса).
Для целей системного анализа архитектура предприятия может рассматриваться в двух аспектах:
Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:
Рассматриваемая в динамике архитектура предприятия - это логически связанный цельный план действий и скоординированных проектов, необходимых для преобразования сложившейся архитектуры организации к состоянию, определенному как долгосрочная цель, базирующийся на текущих и планируемых бизнес-целях и бизнес-процессах организации.
Таким образом, архитектура предприятия в общем случае описывается следующими последовательно зависимыми разделами (см. рис. 1 и рис. 2):
На рис. 1 показано, что выполнение плана миграции не означает замораживания развития бизнес- и системной архитектуры. Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия. Одновременно возврат к стратегическому уровню миссии и стратегических целей и задач не означает необходимость пересмотра миссии и стратегии. Но в конце каждого цикла обязательно проводится анализ эффективности разработанных и осуществленных мероприятий, при необходимости при второй итерации корректируются бизнес-архитектура, системная архитектура, реализуются новые планы миграции. В каждый момент времени может быть несколько циклов, каждый такой цикл не обязательно затрагивает все предприятие в целом, цикл может затрагивать отдельные направления, отдельные вопросы бизнеса и может быть зафиксирован в виде отдельного проекта.
При поэтапном плане миграции для фиксации достигнутых результатов возможно построение промежуточных (миграционных) одной или нескольких архитектур.
Миссия, стратегия и бизнес-цели определяют направления развития банка и ставят долгосрочные цели и задачи.
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые организационную структуру, структуру каналов продаж и функциональную модель банка, документы, используемые в процессе разработки и реализации продуктов. Функциональная модель описывает бизнес-процессы, направленные на реализацию текущих задач и перспективных целей.
Бизнес-архитектура включает в себя:
Системная архитектура (ИТ-архитектура, архитектура ИС предприятия) - определяет совокупность технологических и технических решений для обеспечения информационной поддержки работы банка в соответствии с правилами и концепциями, определенными бизнес-архитектурой.
Далее под «решениями» будем понимать в зависимости от контекста не только конкретное оборудование и программные и информационные системы, но также принципы, стандарты и методологии, используемые при разработке или выборе информационных и программных систем, при выборе и конфигурации оборудования.
Планы миграции определяют сценарий перехода банка от текущего состояния к перспективному, определяемому стратегическими целями и задачами. Планы миграции определяют преобразования как бизнес-, так и системной архитектуры. При поэтапной миграции для целей формализации промежуточных результатов разрабатываются промежуточные (миграционные) одна или несколько бизнес- и системных архитектур. Планы миграции в соответствии с принятой в банке методологией управления проектами формализуются в виде отдельных проектов, включающих, в частности:
Системная архитектура состоит из трех взаимосвязанных компонентов - прикладной архитектуры, архитектуры данных и технической архитектуры (см. рис. 3). Системная архитектура в системе стандартов данного предприятия определяет правила формирования своих компонентов и обеспечения взаимодействия между ними.
Прикладная архитектура включает в себя:
Архитектура данных включает в себя:
Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.
Сетевая архитектура включает в себя:
Архитектура платформ включает в себя:
Для решения задач системной архитектуры в штате компании, как правило, создается выделенная Служба системного архитектора . Эта служба отвечает за решение следующих задач:
Отдельно следует остановиться на одном принципиальном вопросе: кто осуществляет разработку системной архитектуры - системный архитектор или разработчик программного обеспечения, технолог. Правильным является решение, когда ответственность за разработку системной архитектуры закрепляется за ИТ-подразделениями, осуществляющими проектирование, разработку, тестирование, сопровождение (включая вывод из эксплуатации) программно-технических систем и комплексов. Документация по системной архитектуре является частью обязательной проектной и эксплуатационной документации. Этот подход позволяет создать службу системного архитектора небольшой численности. В противном случае разработка системной архитектуры выделенной службой требует значительного увеличения численности системных архитекторов, и процессы разработки либо сильно замедляются, либо разрабатываемая системная архитектура становится неадекватной уже в процессе ее разработки.
Архитектура предприятия полностью описывается следующими сущностями (см. рис. 4):
Рис. 4. Взаимосвязь сущностей верхнего уровня архитектуры предприятия |
На рис. 4 приведены только сущности верхнего уровня. Каждая из сущностей распадается на совокупность более детальных сущностей. Так, только сущность «Продукты» распадается в конечном счете на более чем десять таблиц, включая продуктовые группы, тарифные планы, целевые сегменты клиентов и т. д.
Очевидно, что между всеми этими сущностями имеются сильные взаимосвязи. К примеру, реализация какого-либо продукта сопровождается определенными документами, поддерживается со стороны информационного обеспечения определенными приложениями и модулями, которые используют определенные базы данных. В процессе реализации этого продукта задействованы различные сотрудники и подразделения. Продукт имеет владельца.
Рис. 5. Архитектура предприятия и место в ней системной архитектуры |
На рис. 5 дано укрупненное графическое отображение архитектуры предприятия и определяющих ее компонентов.
Пример ключевых взаимосвязей между основными элементами бизнес-архитектуры и системной архитектуры показан на рис. 6 в форме ER-диаграммы.
Для регламентации жизненных циклов (ЖЦ) систем в целом (в том числе предприятий), а также их информационных систем и программных средств (ПС), в частности, существует ряд стандартов. Они предусматривают возможности приспособления моделей ЖЦ, в том числе фаз (стадий) к особенностям конкретного предприятия и проекта. Таким образом, описанные в данном и следующем разделах фазы ЖЦ не противоречат нормативным и не являются догмой. Их преимуществом в смысле использования в данной статье является простота и опыт практического применения.
Жизненный цикл системной архитектуры состоит из следующих фаз: (см. рис. 7):
ПРИМЕЧАНИЕ. После завершения фазы миграции процесс повторяется, очередная итерация начинается с фазы использования. Фаза начального документирования при разработке новых ИС может отсутствовать. Разработка системной архитектуры начинается с фазы проектирования.
На фазе использования осуществляется эволюционное развитие системной архитектуры в соответствии с ранее сформулированными принципами и без изменения основных технических и технологических решений.
ПРИМЕР. Пусть на фазе проектирования была разработана системная архитектура программы ведения бухгалтерского учета в центральном офисе и филиалах и осуществлено ее внедрение (фаза миграции). Знания о системной архитектуре этого решения переходят в стадию использования до момента возникновения новых бизнес-требований на доработку/модернизацию построенной системы. Знания системной архитектуры созданного решения используются компанией для построения хранилища данных с целью консолидации информации и последующего получения управленческой отчетности. Но основе этих знаний проектируется системная архитектура хранилища данных и затем системы управленческой отчетности, которые в последующем, пройдя свои стадии миграций, входят в фазы использования. Таким образом, можно говорить о многослойной модели системной архитектуры, в которой системная архитектура в различных слоях может находиться на различных стадиях жизненного цикла (см. рис. 8).
На фазе проектирования проводится разработка перспективной (to be) системной архитектуры, формулируются новые принципы построения системной архитектуры, вырабатываются в соответствии с этими принципами новые основные технические и технологические решения. Обычно причиной исполнения этой фазы являются существенные изменения в бизнес-архитектуре, появление новых бизнес-требований, существенным образом влияющих на системную архитектуру.
На фазе миграции осуществляется комплекс организационных, технических и технологических мероприятий, обеспечивающих переход системной архитектуры от текущего состояния к перспективному или к очередному промежуточному состоянию при поэтапной миграции в соответствии с подготовленными на предыдущей фазе миграционными планами.
Жизненный цикл системной архитектуры связан с жизненным циклом программных средств. Жизненный цикл программных средств (ПС) состоит из следующих основных фаз:
Системный архитектор выполняет контроль проектных решений на всем жизненном цикле программных средств. Контроль осуществляется в форме согласования проектных документов, подготавливаемых и направляемых системному архитектору подразделениями, ответственными за реализацию той или иной фазы жизненного цикла ПС.
Описания фаз ЖЦ системной архитектуры, состава работ по системной архитектуре, проводимых в каждой фазе, исполнителей этих работ, а также соответствия фазам жизненного цикла ПС представлены ниже.
Фазе жизненного цикла системной архитектуры «Начальное документирование» нет прямого соответствия в фазах ЖЦ программных средств. Содержательно эта фаза представлена функциями ее активных участников (см. табл. 1).
Фазе жизненного цикла системной архитектуры «Использование» соответствуют следующие фазы ЖЦ программных средств:
Здесь может возникнуть вопрос: а куда делась разработка постановки задачи? И нужна ли она вообще? Фазе жизненного цикла системной архитектуры «Проектирование» соответствуют следующие фазы ЖЦ программных средств:
Безусловно, нужна, выражаясь казенным языком, фаза «Анализ объекта автоматизации», включая разработку постановки задачи, формулирование бизнес-требований, и такая фаза, конечно, есть. Однако детальное рассмотрение этих вопросов выходит за рамки статьи, которая ограничена рассмотрением системной архитектуры.
Все же поясним. Потребность в изменении бизнеса и, как следствие, необходимость перестройки бизнес-архитектуры может быть обусловлена:
После осознания этой потребности производится формулирование бизнес-требований, но все это происходит, когда мы еще находимся в слое бизнес-архитектуры (см. ). Стрелки от сущностей «Продукты» и «Документы», направленные к сущностям «Оборудование», «Программы» и «Данные», соответствуют постановке задачи (бизнес-требованиям). Вернемся к нашему примеру, из которого мы видим, что разработка ТЗ, ТП, тестирование и внедрение хранилища данных используют знания о системной архитектуре системы бухгалтерского учета, которая уже находится в промышленной эксплуатации, а ее системная архитектура в настоящий момент находится в фазе использования. Системная же архитектура хранилища данных в настоящий момент находится в фазе проектирования (см. рис. 8).
Функции активных участников фазы «Проектирование» представлены в табл. 3 .
Фазе жизненного цикла системной архитектуры «Миграция» соответствуют следующие фазы ЖЦ программных средств:
Функции активных участников фазы «Миграция» представлены в табл. 4 .
Таким образом, системная архитектура реально затрагивается на следующих фазах ЖЦ программных средств:
Поскольку только перечни того, что необходимо знать о системной архитектуре, очень велики для изложения в журнальной статье (они составляют десятки позиций), далее описаны лишь разделы соответствующей базы знаний и сделана попытка хотя бы наметить содержание этих разделов.
База знаний о системной архитектуре должна состоять как минимум из трех разделов:
Разделы «Текущая системная архитектура» и «Перспективная системная архитектура» имеют одинаковую структуру и состоят из следующих подразделов:
Приводятся требования и ограничения, предъявляемые к системной архитектуре со стороны бизнес-архитектуры. Указываются все требования и ограничения - как сформулированные непосредственно в бизнес-архитектуре, так и дополнительные, сформулированные системным архитектором.
Приводится описание принципов построения системной архитектуры, вытекающих из указанных выше требований и ограничений.
Описываются главные технические и технологические решения, составляющие основу системной архитектуры. Например, это может быть решение об использовании ЭВМ AS/400 в качестве основной аппаратной платформы информационной системы банка или решение об использовании СУБД DB2 в качестве основного инструмента управления информационными ресурсами банка.
Каждое решение снабжается комментарием, поясняющим, каким образом данное решение соответствует сформулированным выше принципам построения системной архитектуры.
Главные решения, принимаемые в ходе проектирования системной архитектуры, оформляются отдельными документами, с кратким изложением предыстории, сути проблемы и принятого принципиального решения проблемы, обязательного в последующем при проектировании, разработке и внедрении информационной системы.
Указываются все требования, стандарты и ограничения, которым соответствует системная архитектура. При необходимости отдельные стандарты (требования, ограничения) или ссылки на них могут быть продублированы в последующих главах.
Описываются внутренние стандарты (стандарты предприятия) с указанием кода (если присвоен), наименования, редакции и утвердившего органа.
Описываются дополнительные требования и ограничения, которым должна удовлетворять системная архитектура и элементы информационной инфраструктуры, не получившие статуса стандарта.
Поясняется, какие именно принципы построения системной архитектуры или принятые основные технические и технологические решения обусловили необходимость использования/учета данного стандарта/требования или ограничения.
Описываются прикладные системы (приложения), обеспечивающие исполнение бизнес-функций и бизнес-процессов и их взаимодействие. Уровень детализации описания должен соответствовать программному модулю, понимаемому как программная единица, самостоятельно хранимая в виде файла или раздела библиотеки.
Содержит описания территориальной коммуникационной инфраструктуры и локальных вычислительных сетей (ЛВС).
Содержит описание операционных систем и оборудования раздельно по серверам и рабочим станциям.
Базы и хранилища данных
Содержит описание баз данных и иным способом организованных информационных массивов.
Системы управления базами данных
Содержит описание используемых систем управления базами данных.
Содержит план миграции от текущей системной архитектуры к перспективной.
Если предполагается поэтапная миграция, то сюда же включаются промежуточные миграционные планы.
Как указывалось ранее, план миграции оформляется в виде проекта. Таким образом, по каждому плану в раздел включаются все документы, предусмотренные принятой в Банке методологией управления проектами, как утвержденные, так и находящиеся в стадии разработки или согласования.
Выше мы показали, что состав и содержание знаний о системной архитектуре представляют собой глубоко структурированный набор сильно взаимосвязанных сведений. Причем взаимосвязи не ограничиваются связями между сущностями системной архитектуры (см. рис. 3), но и тесно связаны с сущностями бизнес-архитектуры. Так, на практике часто возникает необходимость найти ответ на следующие вопросы:
Конечно, возникает также множество других вопросов, так или иначе связанных с системной и бизнес-архитектурой.
В силу ограниченного размера журнальной статьи разбор этих вопросов выходит за ее пределы. Отметим только, что для структуризации и документирования этих знаний возможностями программ MS Word или MS Excel не обойтись. Необходимо использование более развитых программных комплексов, но еще важнее использование соответствующих методик или даже методологий. Одним из таких руководств, которое, по опыту автора, удовлетворяет нужным требованиям, является «методология ARIS» (ARchitecture of Integrated Information System). Однако это совершенно другая тема, возможно, для другой статьи.