Системная архитектура и ее место в архитектуре предприятия. Системный архитектор: обучение, должностная инструкция и отзывы

Введение

Термин архитектура все чаще используется вне традиционного строительного контекста, и уже сейчас можно встретить много определений архитектуры (в контексте систем) и архитектуры систем, например:

"Архитектура системы: единая фундаментальная структура системы, описанная в терминах поведения, ограничений, процессов, интерфейсов и элементов системы".
[базовое определение, одобренное 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, в которой основное внимание уделяется активным классам системы. В точки наблюдения определенных предметных областей также входят представления рабочих продуктов для одного или нескольких уровней. Набор рабочих продуктов проекта в данной среде должен представлять собой вариант разработки проекта.

Лекция 2. «Системная архитектура и ее место в архитектуре предприятия».

В современных условиях особенно важно постоянно и правильно согласовывать ИТ-аспекты устройства современного автоматизированного предприятия с актуальными бизнес-аспектами. Делать это надо начиная с определения бизнес-архитектуры предприятия и согласованной с ней разработки системной архитектуры (ИТ-архитектуры). В предлагаемой статье автор делится практическим опытом разработки системных архитектур крупных банков и дает конкретные советы, как это можно делать - в том числе для предприятий иных отраслей.

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

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

Следует отметить, что архитектура предприятия существует независимо как от нашего сознания, так и от размера этого предприятия - будь то глобальная корпорация, небольшой завод, малое торговое предприятие и т. п. У малого предприятия архитектура есть так же, как и у крупного, при этом они не слишком сильно различаются по составу компонентов. Однако одни руководители это понимают и могут себе позволить уделять внимание всем аспектам устройства своего же предприятия (это, как правило, руководители крупных компаний), а другие - нет. Иное дело, что у малого предприятия могут быть всего два-три продукта, миссия и стратегия в явной форме не зафиксированы (эта беда, кстати, встречается часто и в крупных компаниях), количество сотрудников составляет 30 человек и в производстве используется два компьютера с MS Word 97. Но и в таком случае это все и составляет архитектуру данного предприятия.

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

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

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

Базовые понятия

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

Для целей системного анализа архитектура предприятия может рассматриваться в двух аспектах:

статическом - по состоянию банка в некоторый фиксированный момент времени;

динамическом - как процесс перехода (миграции) банка от текущего состояния к некоторому желаемому состоянию в будущем.

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

миссия и стратегия, стратегические цели и задачи;

бизнес-архитектура;

системная архитектура.

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

Таким образом, архитектура предприятия в общем случае описывается следующими последовательно зависимыми разделами (см. рис. 1 и рис. 2):

сформулированные миссия и стратегия банка, стратегические цели и задачи;

бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,

системная архитектура в текущем (as is) и планируемом (to be) состоянии;

планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Рисунок 1.

На рис. 1 показано, что выполнение плана миграции не означает замораживания развития бизнес- и системной архитектуры. Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия. Одновременно возврат к стратегическому уровню миссии и стратегических целей и задач не означает необходимость пересмотра миссии и стратегии. Но в конце каждого цикла обязательно проводится анализ эффективности разработанных и осуществленных мероприятий, при необходимости при второй итерации корректируются бизнес-архитектура, системная архитектура, реализуются новые планы миграции. В каждый момент времени может быть несколько циклов, каждый такой цикл не обязательно затрагивает все предприятие в целом, цикл может затрагивать отдельные направления, отдельные вопросы бизнеса и может быть зафиксирован в виде отдельного проекта.

При поэтапном плане миграции для фиксации достигнутых результатов возможно построение промежуточных (миграционных) одной или нескольких архитектур.

Миссия, стратегия и бизнес-цели определяют направления развития банка и ставят долгосрочные цели и задачи.

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

Бизнес-архитектура включает в себя:

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

каналы продажи продуктов и услуг, построенные как на базе структурных и территориальных подразделений банка, так и на базе современных информационных технологий;

функции и процессы по реализации внешних и внутренних продуктов и услуг, образующие деревья функций и процессов (далее - бизнес-функции и бизнес-процессы);

финансовые и распорядительные документы (как в бумажном, так и в электронном виде), формализованные в виде единого реестра (альбома форм) документов банка;

документопотоки, определяемые нормативными актами по внутреннему и внешнему документообороту;

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

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

Далее под «решениями» будем понимать в зависимости от контекста не только конкретное оборудование и программные и информационные системы, но также принципы, стандарты и методологии, используемые при разработке или выборе информационных и программных систем, при выборе и конфигурации оборудования.

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

определение проекта как совокупности задач и работ;

фазы и сроки реализации проекта в целом и составляющих проект задач и работ;

анализ конкурентной среды и рисков, связанных с реализацией проекта;

состав статей расхода бюджета проекта;

критерии успешности реализации проекта и ожидаемый экономический эффект.

Системная архитектура

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

Прикладная архитектура включает в себя:

прикладные системы (приложения), обеспечивающие исполнение бизнес- функций и бизнес-процессов;

интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных;

средства и методы разработки и сопровождения приложений.

Архитектура данных включает в себя:

автоматизированные базы данных, обеспечивающие накопление, хранение и обработку данных, определяемых бизнес-архитектурой;

применяемые для этого системы управления базами данных или хранилищами данных;

правила и средства санкционирования доступа к данным.

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.

Сетевая архитектура включает в себя:

локальные и территориальные вычислительные сети, включая физические собственные и арендованные каналы связи и каналообразующую аппаратуру;

используемые в сетях коммуникационные протоколы, сервисы и системы адресации;

аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает в себя:

аппаратные средства вычислительной техники - серверы, рабочие станции, накопители и другое компьютерное оборудование;

операционные и управляющие системы, утилиты и офисные программные системы;

аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом - серверов) и баз данных в условиях чрезвычайных обстоятельств.

Для решения задач системной архитектуры в штате компании, как правило, создается выделенная Служба системного архитектора. Эта служба отвечает за решение следующих задач:

координация работ ИТ-подразделений по документированию текущей системной архитектуры на начальном этапе и последующее поддержание базы знаний о системной архитектуре в актуальном состоянии;

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

проектирование (совместно с другими профильными подразделениями по информационным технологиям) перспективной системной архитектуры и планов миграции от текущего состояния к перспективному;

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

контроль непротиворечивости системных архитектур, разработанных в рамках различных проектов;

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

Отдельно следует остановиться на одном принципиальном вопросе: кто осуществляет разработку системной архитектуры - системный архитектор или разработчик программного обеспечения, технолог. Правильным является решение, когда ответственность за разработку системной архитектуры закрепляется за ИТ-подразделениями, осуществляющими проектирование, разработку, тестирование, сопровождение (включая вывод из эксплуатации) программно-технических систем и комплексов. Документация по системной архитектуре является частью обязательной проектной и эксплуатационной документации. Этот подход позволяет создать службу системного архитектора небольшой численности. В противном случае разработка системной архитектуры выделенной службой требует значительного увеличения численности системных архитекторов, и процессы разработки либо сильно замедляются, либо разрабатываемая системная архитектура становится неадекватной уже в процессе ее разработки.

Взаимосвязи системной архитектуры и бизнес-архитектуры

Архитектура предприятия полностью описывается следующими сущностями (см. рис. 4):

Миссия и стратегия банка, стратегические цели и задачи.

Продукты и бизнес-процессы.

Документы.

Организационная структура.

Приложения.

Оборудование.
Планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Рисунок 4.

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

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

Рисунок 5.

На рис. 5 дано укрупненное графическое отображение архитектуры предприятия и определяющих ее компонентов.

Пример ключевых взаимосвязей между основными элементами бизнес-архитектуры и системной архитектуры показан на рис. 6 в форме ER-диаграммы.

Жизненный цикл системной архитектуры

Для регламентации жизненных циклов (ЖЦ) систем в целом (в том числе предприятий), а также их информационных систем и программных средств (ПС), в частности, существует ряд стандартов. Они предусматривают возможности приспособления моделей ЖЦ, в том числе фаз (стадий) к особенностям конкретного предприятия и проекта. Таким образом, описанные в данном и следующем разделах фазы ЖЦ не противоречат нормативным и не являются догмой. Их преимуществом в смысле использования в данной статье является простота и опыт практического применения.

Жизненный цикл системной архитектуры состоит из следующих фаз: (см. рис. 7):

начальное документирование;

использование;

проектирование;

миграция.

ПРИМЕЧАНИЕ. После завершения фазы миграции процесс повторяется, очередная итерация начинается с фазы использования. Фаза начального документирования при разработке новых ИС может отсутствовать. Разработка системной архитектуры начинается с фазы проектирования.

На фазе использования осуществляется эволюционное развитие системной архитектуры в соответствии с ранее сформулированными принципами и без изменения основных технических и технологических решений.

ПРИМЕР. Пусть на фазе проектирования была разработана системная архитектура программы ведения бухгалтерского учета в центральном офисе и филиалах и осуществлено ее внедрение (фаза миграции). Знания о системной архитектуре этого решения переходят в стадию использования до момента возникновения новых бизнес-требований на доработку/модернизацию построенной системы. Знания системной архитектуры созданного решения используются компанией для построения хранилища данных с целью консолидации информации и последующего получения управленческой отчетности. Но основе этих знаний проектируется системная архитектура хранилища данных и затем системы управленческой отчетности, которые в последующем, пройдя свои стадии миграций, входят в фазы использования. Таким образом, можно говорить о многослойной модели системной архитектуры, в которой системная архитектура в различных слоях может находиться на различных стадиях жизненного цикла (см. рис. 8).

На фазе проектирования проводится разработка перспективной (to be) системной архитектуры, формулируются новые принципы построения системной архитектуры, вырабатываются в соответствии с этими принципами новые основные технические и технологические решения. Обычно причиной исполнения этой фазы являются существенные изменения в бизнес-архитектуре, появление новых бизнес-требований, существенным образом влияющих на системную архитектуру.

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

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

анализ осуществимости;

разработка технического задания;

разработка технического проекта;

разработка и документирование ПС;

тестирование ПС;

внедрение ПС;

эксплуатация ПС;

вывод ПС из эксплуатации.

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

Описания фаз ЖЦ системной архитектуры, состава работ по системной архитектуре, проводимых в каждой фазе, исполнителей этих работ, а также соответствия фазам жизненного цикла ПС представлены ниже.

Начальное документирование

Фазе жизненного цикла системной архитектуры «Начальное документирование» нет прямого соответствия в фазах ЖЦ программных средств. Содержательно эта фаза представлена функциями ее активных участников (см. табл. 1).

Использование

Фазе жизненного цикла системной архитектуры «Использование» соответствуют следующие фазы ЖЦ программных средств:

Разработка технического задания на ПС.

Разработка технического проекта ПС.

Тестирование ПС.

(См. примечание, рис. 8 и пример выше. Из примера мы видим, что разработка ТЗ, ТП, тестирование и внедрение хранилища данных и системы управленческой отчетности используют знания о системной архитектуре системы бухгалтерского учета, находящейся в промышленной эксплуатации, и системная архитектура которой в настоящий момент находится в фазе использования. Системная же архитектура хранилища данных в настоящий момент находится в фазе проектирования.)

Функции ее активных участников фазы «Использование» представлены в табл. 2.

Проектирование

Здесь может возникнуть вопрос: а куда делась разработка постановки задачи? И нужна ли она вообще? Фазе жизненного цикла системной архитектуры «Проектирование» соответствуют следующие фазы ЖЦ программных средств:

Подготовка технического задания на ПС.

Подготовка технического проекта ПС.

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

Все же поясним. Потребность в изменении бизнеса и, как следствие, необходимость перестройки бизнес-архитектуры может быть обусловлена:

изменениями миссии или стратегии;

изменениями рыночной ситуации;

регулирующими органами.

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

Функции активных участников фазы «Проектирование» представлены в табл. 3.

Миграция

Фазе жизненного цикла системной архитектуры «Миграция» соответствуют следующие фазы ЖЦ программных средств:

Тестирование программных средств.

Внедрение программных средств.

Функции активных участников фазы «Миграция» представлены в табл. 4.

Таким образом, системная архитектура реально затрагивается на следующих фазах ЖЦ программных средств:

На фазе "Разработка технического задания на ПС" производится анализ существующей системной архитектуры с целью возможности и целесообразности использования существующих ресурсов для решения вновь поставленных бизнес-задач. Кроме того, при подготовке технического задания по возможности учитываются требования и ограничения, накладываемые существующей системной архитектурой.

На фазе "Разработка технического проекта ПС" производится собственно формирование или изменение системной архитектуры, необходимое для реализации вновь поставленных бизнес-задач. Требования и ограничения, накладываемые существующей системной архитектурой, учитываются в целях обеспечения преемственности и минимизации расходов на модернизацию.

На фазах "Тестирование" и "Внедрение" разработанных программных средств требования системной архитектуры используются для формирования необходимой технологической среды для проведения испытаний и эксплуатации этих ПС.

Состав базы знаний по системной архитектуре

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

База знаний о системной архитектуре должна состоять как минимум из трех разделов:

Текущая системная архитектура.

Перспективная (планируемая) системная архитектура.

Планы миграции.

Разделы «Текущая системная архитектура» и «Перспективная системная архитектура» имеют одинаковую структуру и состоят из следующих подразделов:

Принципы построения системной архитектуры.

Основные технические и технологические решения.

Требования и стандарты.

Прикладная архитектура.

Техническая архитектура.

Архитектура данных.

Принципы построения

Приводятся требования и ограничения, предъявляемые к системной архитектуре со стороны бизнес-архитектуры. Указываются все требования и ограничения - как сформулированные непосредственно в бизнес-архитектуре, так и дополнительные, сформулированные системным архитектором.

Приводится описание принципов построения системной архитектуры, вытекающих из указанных выше требований и ограничений.

Основные решения

Описываются главные технические и технологические решения, составляющие основу системной архитектуры. Например, это может быть решение об использовании ЭВМ AS/400 в качестве основной аппаратной платформы информационной системы банка или решение об использовании СУБД DB2 в качестве основного инструмента управления информационными ресурсами банка.

Каждое решение снабжается комментарием, поясняющим, каким образом данное решение соответствует сформулированным выше принципам построения системной архитектуры.

Собрана на сайте Университета Карнеги - Меллона .

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

Другие определения архитектуры системы

Энциклопедичный YouTube

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 .

Архитектурная группа описаний (англ. architectural view ) - представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру . Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания.
Архитектурное описание (англ. architectural description ) - рабочий продукт, использующийся для выражения архитектуры.
Архитектурный подход (англ. architectural framework ) - соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом стейкхолдеров.
Архитектурный метод описания (англ. architectural viewpoint ) - спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам.
Вид модели (англ. model kind ) - соглашения по средствам моделирования (например, сети Петри , диаграммы классов , организационные диаграммы и т. д.).

Виды архитектуры

Свод знаний по системной инженерии (SEBoK) делит архитектуру на логическую и физическую :269 .

Логическая архитектура

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

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

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

Временная архитектура . Временная архитектура является классификацией функций системы, которая получена в соответствии с уровнем частоты её исполнения. Временная архитектура включает в себя определение синхронных и асинхронных аспектов функций. Мониторинг решений, который происходит внутри системы, следует той же временной классификации :287 .

Физическая архитектура

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

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

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

Архитектурное описание

Архитектура может быть зафиксирована с помощью полного архитектурного описания (АО) (см. рисунок). Стандарт ISO/IEC/IEEE 42010-2011 предписывает различать концептуальную архитектуру системы и одно из описаний данной архитектуры, являющееся конкретным продуктом или артефактом.

В сложных системах АО может разрабатываться не только для системы в целом, но и для компонентов системы. Два разных концептуальных АО могут включать группы описаний, которые будут соответствовать одному и тому же методу описания. Хотя системы, описываемые данными двумя группами описаний, будут соотноситься как целое и часть, это не пример множества групп описаний, соответствующих одному методу. Эти АО считаются отдельными, даже хотя они связаны через системы, которые они описывают :3 .

Концептуальный подход

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

На рисунке прямоугольники изображают классы сущностей.

Линии, соединяющие прямоугольники, изображают связи между сущностями. Связь включает две роли (по одной в каждом направлении). Каждая роль может по желанию быть именована меткой. Роль, направленная от A к B, [помечена] ближе к B, и наоборот. Например, роли между «системой» и «средой» могут читаться: «„система“ живёт в „среде“» и «„среда“ влияет на „систему“». На рисунке роли обладают арностью 1:1, если не указано иное. Роль может обладать множественной арностью, например, роль, обозначенная как «1..*», применяется для обозначения многих, как в связях «один ко многим» или «многие к одному». Ромб (на конце линии связи) обозначает отношение части целого. Например, «группы описаний» являются частью «архитектурного описания». Эта нотация заимствована из UML.

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

Система обитает в некоторой среде. Среда некоторой системы может влиять на данную систему. Её среда, или контекст, определяет обстановку и обстоятельства разработки, эксплуатации, политических и иных влияний на данную систему. Такая среда может включать другие системы, взаимодействующие с целевой системой, как напрямую через интерфейсы, так и косвенно иными путями. Такая среда определяет границы, определяющие предмет целевой системы по отношению к другим системам.

У каждой системы есть один или более стейкхолдеров . Каждый стейкхолдер обычно принимает участие в системе, или имеет интересы к данной системе. Интересы предполагают учёт таких аспектов системы как производительность, надежность, безопасность, распределённость и способность к эволюции.

Любая система существует для реализации в своей среде одной или более миссий.

В концептуальном подходе архитектурное описание организовано как одна или более архитектурных групп описаний.

Архитектурное описание выбирает для применения один или более подходящих методов описания. Выбор методов описания обычно основывается на соображениях и интересах заинтересованных сторон, которым адресовано это АО. Определение метода описания может возникать совместно с АО, а может быть определено отдельно. Метод описания, определенный отдельно от АО называется библиотечным методом описания.

Группа описаний может состоять из одного или более архитектурных описаний. Каждое такое архитектурное описание разрабатывается с применением установленных соответствующим ему методов архитектурного описания. Архитектурное описание может входить более чем в одну группу описаний :4-6 .

Типы групп описаний архитектуры

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

Функциональная группа описаний

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

Логическая группа описаний

Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть блочные диаграммы функциональных потоков

Я - географ, а не путешественник. Мне ужасно не хватает путешественников. Ведь не географы ведут счет городам, рекам, горам, морям, океанам и пустыням. Географ - слишком важное лицо, ему некогда разгуливать. Он не выходит из своего кабинета. Но он принимает у себя путешественников и записывает их рассказы.

Антуан де Сент-Экзюпери. «Маленький принц». Глава 15. Географ

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

Следует отметить, что архитектура предприятия существует независимо как от нашего сознания, так и от размера этого предприятия - будь то глобальная корпорация, небольшой завод, малое торговое предприятие и т. п. У малого предприятия архитектура есть так же, как и у крупного, при этом они не слишком сильно различаются по составу компонентов. Однако одни руководители это понимают и могут себе позволить уделять внимание всем аспектам устройства своего же предприятия (это, как правило, руководители крупных компаний), а другие - нет. Иное дело, что у малого предприятия могут быть всего два-три продукта, миссия и стратегия в явной форме не зафиксированы (эта беда, кстати, встречается часто и в крупных компаниях), количество сотрудников составляет 30 человек и в производстве используется два компьютера с MS Word 97. Но и в таком случае это все и составляет архитектуру данного предприятия.

Базовые понятия

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

Для целей системного анализа архитектура предприятия может рассматриваться в двух аспектах:

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

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

миссия и стратегия, стратегические цели и задачи;
бизнес-архитектура;
системная архитектура.

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

сформулированные миссия и стратегия банка, стратегические цели и задачи;
бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,
системная архитектура в текущем (as is) и планируемом (to be) состоянии;
планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Миссия, стратегия и бизнес-цели определяют направления развития банка и ставят долгосрочные цели и задачи.

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

Бизнес-архитектура включает в себя:

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

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

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

определение проекта как совокупности задач и работ;
фазы и сроки реализации проекта в целом и составляющих проект задач и работ;
анализ конкурентной среды и рисков, связанных с реализацией проекта;
состав статей расхода бюджета проекта;
критерии успешности реализации проекта и ожидаемый экономический эффект.

Системная архитектура

Прикладная архитектура включает в себя:

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

Архитектура данных включает в себя:

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

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.

Сетевая архитектура включает в себя:

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

Архитектура платформ включает в себя:

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

Для решения задач системной архитектуры в штате компании, как правило, создается выделенная Служба системного архитектора . Эта служба отвечает за решение следующих задач:

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

Взаимосвязи системной архитектуры и бизнес-архитектуры

Архитектура предприятия полностью описывается следующими сущностями (см. рис. 4):

Миссия и стратегия банка, стратегические цели и задачи.
Продукты и бизнес-процессы.
Документы.
Организационная структура.
Приложения.
Данные.
Оборудование.
Планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Рис. 4. Взаимосвязь сущностей верхнего уровня архитектуры предприятия

Рис. 5. Архитектура предприятия и место в ней системной архитектуры

На рис. 5 дано укрупненное графическое отображение архитектуры предприятия и определяющих ее компонентов.

Жизненный цикл системной архитектуры

Жизненный цикл системной архитектуры состоит из следующих фаз: (см. рис. 7):

начальное документирование;
использование;
проектирование;
миграция.

анализ осуществимости;
разработка технического задания;
разработка технического проекта;
разработка и документирование ПС;
тестирование ПС;
внедрение ПС;
эксплуатация ПС;
вывод ПС из эксплуатации.

Начальное документирование

Использование

Разработка технического задания на ПС.
Разработка технического проекта ПС.
Тестирование ПС.

Проектирование

Подготовка технического задания на ПС.
Подготовка технического проекта ПС.

изменениями миссии или стратегии;
изменениями рыночной ситуации;
регулирующими органами.

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

Функции активных участников фазы «Проектирование» представлены в табл. 3 .

Миграция

Тестирование программных средств.
Внедрение программных средств.

Функции активных участников фазы «Миграция» представлены в табл. 4 .

Таким образом, системная архитектура реально затрагивается на следующих фазах ЖЦ программных средств:

На фазе "Разработка технического задания на ПС" производится анализ существующей системной архитектуры с целью возможности и целесообразности использования существующих ресурсов для решения вновь поставленных бизнес-задач. Кроме того, при подготовке технического задания по возможности учитываются требования и ограничения, накладываемые существующей системной архитектурой.
На фазе "Разработка технического проекта ПС" производится собственно формирование или изменение системной архитектуры, необходимое для реализации вновь поставленных бизнес-задач. Требования и ограничения, накладываемые существующей системной архитектурой, учитываются в целях обеспечения преемственности и минимизации расходов на модернизацию.
На фазах "Тестирование" и "Внедрение" разработанных программных средств требования системной архитектуры используются для формирования необходимой технологической среды для проведения испытаний и эксплуатации этих ПС.

Состав базы знаний по системной архитектуре

База знаний о системной архитектуре должна состоять как минимум из трех разделов:

Текущая системная архитектура.
Перспективная (планируемая) системная архитектура.
Планы миграции.

Принципы построения системной архитектуры.
Основные технические и технологические решения.
Требования и стандарты.
Прикладная архитектура.
Техническая архитектура.
Архитектура данных.

Принципы построения

Основные решения

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

Требования и стандарты

Указываются все требования, стандарты и ограничения, которым соответствует системная архитектура. При необходимости отдельные стандарты (требования, ограничения) или ссылки на них могут быть продублированы в последующих главах.

Описываются внутренние стандарты (стандарты предприятия) с указанием кода (если присвоен), наименования, редакции и утвердившего органа.

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

Поясняется, какие именно принципы построения системной архитектуры или принятые основные технические и технологические решения обусловили необходимость использования/учета данного стандарта/требования или ограничения.

Прикладная архитектура

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

Техническая архитектура

Сетевая архитектура

Содержит описания территориальной коммуникационной инфраструктуры и локальных вычислительных сетей (ЛВС).

Архитектура платформ

Содержит описание операционных систем и оборудования раздельно по серверам и рабочим станциям.

Архитектура данных

Базы и хранилища данных

Содержит описание баз данных и иным способом организованных информационных массивов.

Системы управления базами данных

Содержит описание используемых систем управления базами данных.

План миграции

Содержит план миграции от текущей системной архитектуры к перспективной.

Если предполагается поэтапная миграция, то сюда же включаются промежуточные миграционные планы.

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

Заключение

Выше мы показали, что состав и содержание знаний о системной архитектуре представляют собой глубоко структурированный набор сильно взаимосвязанных сведений. Причем взаимосвязи не ограничиваются связями между сущностями системной архитектуры (см. рис. 3), но и тесно связаны с сущностями бизнес-архитектуры. Так, на практике часто возникает необходимость найти ответ на следующие вопросы:

Кто в банке выполняет ту или иную бизнес-функцию, насколько регулярно выполняет, какое событие вызывает выполнение этой бизнес-функции, автоматизировано или нет автоматизировано или выполнение этой бизнес-функции?
Какая информация является входящей для той или иной бизнес-функции, кто является поставщиком этой информации, в каком виде она поступает?
Какие программные средства используются для выполнения той или иной бизнес-функции, какие еще ИТ-функции выполняют эти программы, какие базы данных и справочники используются, какие экраны и какие отчеты формируются программой?
Какая информация является входящей и выходящей для той или иной программы, в каком виде поступает входящая информация и формируется исходящая?
Каким образом организовано информационное взаимодействие двух программ: через формирование/чтение файла, непосредственно через API, через электронную почту, через системы уровня middleware, какова структура информационного обмена, какова периодичность?
Какие подразделения используют ту или иную программу, кого нужно уведомить при изменении программы или какого-либо регламента?
Используется ли в настоящий момент та или иная ИТ-функция программы, кем используется, насколько часто?

Конечно, возникает также множество других вопросов, так или иначе связанных с системной и бизнес-архитектурой.

В силу ограниченного размера журнальной статьи разбор этих вопросов выходит за ее пределы. Отметим только, что для структуризации и документирования этих знаний возможностями программ MS Word или MS Excel не обойтись. Необходимо использование более развитых программных комплексов, но еще важнее использование соответствующих методик или даже методологий. Одним из таких руководств, которое, по опыту автора, удовлетворяет нужным требованиям, является «методология ARIS» (ARchitecture of Integrated Information System). Однако это совершенно другая тема, возможно, для другой статьи.

Инициация планирования

Этап включает в себя семь шагов, цели, задачи и основные результаты которых описаны далее.

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

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

Целью второго шага является исследование предприятия, системных входов/выходов и вариантов на основании встреч с менеджментом. Результатами являются согласованное и утвержденное видение предприятия, а также политическая поддержка менеджмента.

Основными задачами шага являются:

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

Целью третьего шага является адаптация методологии планирования и создание руководства по методологии. Основными задачами шага являются:

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

Целью четвертого шага является наведение порядка с компьютерными ресурсами и оценка инструментария создания ЕА. Основными задачами шага являются:

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

Цель пятого шага — создание проектной команды. Основными задачами шага являются:

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

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

Предварительное бизнес-моделирование

Целью бизнес-моделирования является обеспечение полной и исчерпывающей базой знаний всех участников проекта для ее использования при определении архитектуры и плана ее реализации.

Бизнес-моделирование осуществляется в два этапа-построение предварительной бизнес-модели, за которым следует построение полной бизнес-модели.

Предварительная бизнес-модель идентифицирует функции, дает их описания и идентифицирует организационные единицы — исполнителей функций. По оценкам ряда экспертов этап требует 25-30% всех трудозатрат на моделирование, он осуществляется в три шага.

Первый шаг — документирование организационной структуры предприятия — в качестве результатов получают обновленные организационные схемы, перечень ролей и мест их выполнения, оценку количества сотрудников по ролям.

Основными задачами шага являются:

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

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

Основными задачами шага являются:

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

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

формирование отчетов по бизнес-модели;
распространение отчетов и проведение презентации;
сбор замечаний и предложений.

Формирование снимка предприятия

Этап включает в себя следующие три шага:

планирование, подготовка и проведение интервью;
построение бизнес-модели;
распространение и анализ бизнес-модели.

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

На следующих шагах осуществляется обработка результатов интервью, построение детальной модели, ее анализ, формирование пакета отчетов и проведение презентации.

Описание текущих систем и технологий

Целью этапа является документирование всех используемых на предприятии системных и технологических платформ, т. е. создание так называемого каталога информационных ресурсов IRC (Information Resource Catalog), по-другому — системной энциклопедии, являющейся высокоуровневым объектом, а не детальным словарем данных.

Целью первого шага является определение видов данных для IRC и проектирование форм для сбора данных.

Основные задачи шага включают:

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

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

сбор системной документации;
сопоставление приложений и бизнес-функций и формирование соответствующей матрицы;
сопоставление приложений и технологических платформ и формирование соответствующей матрицы;
ввод информации в инструментарий.

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

На четвертом шаге осуществляется подготовка к администрированию и сопровождению IRC для его поддержки в актуальном состоянии. Здесь разрабатывается регламент поддержки, политики и процедуры сопровождения IRC, назначается ответственный по его сопровождению.

Формирование архитектуры данных

На этом этапе идентифицируются и определяются основные разновидности данных, поддерживающих бизнес-функции. Архитектура данных представляется с помощью ER-модели и состоит из сущностей данных, каждая из которых имеет атрибуты и отношения с другими сущностями.

Этап содержит четыре шага:

формирование списка кандидатов в сущности (трудозатраты — 10%);
определение сущностей, атрибутов и отношений (трудозатраты — 60%);
сопоставление сущностей и бизнес-функций (трудозатраты — 20%);

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

Целью второго шага является создание стандартного определения и описания каждой сущности, обеспечение графической иллюстрации их взаимодействий. Здесь сущности определяются и документируются, осуществляется построение ER-модели, производится сопоставление файлов и БД из IRC с сущностями.

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

Целью четвертого шага является подготовка, распространение и анализ отчета по архитектуре данных.

Формирование архитектуры приложений

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

формирование списка кандидатов в приложения (трудозатраты — 10%);
определение приложений (трудозатраты — 50%);
сопоставление приложений и функций (трудозатраты — 15%);
анализ применимости существующих приложений (трудозатраты — 15%);
анализ результатов (трудозатраты — 10%).

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

Цель второго шага — снабдить каждое приложение стандартным описанием (определением) и построить графическую схему архитектуры приложений. Основными задачами шага являются:

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

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

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

На пятом шаге производится подготовка, распространение и анализ отчета по архитектуре приложений.

Формирование технической архитектуры

Этот этап определяет основные виды технологий, необходимых для обеспечения окружения приложений, управляющих данными. Техническая архитектура не является ни проектом сетевого оборудования и ПО, ни детальными требованиями к ним. Она только определяет виды технических платформ, поддерживающих бизнес.

Основными шагами этапа являются:

идентификация технических принципов и платформ (трудозатраты — 15%);
определение платформ и их распределение (трудозатраты — 50%);
сопоставление платформ с приложениями и бизнес-функциями (трудозатраты — 20%);
анализ результатов (трудозатраты — 15%).

Целью первого шага является формулирование общих принципов для технических платформ и идентификация потенциальных кандидатов в платформы.

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

Основными задачами шага являются:

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

Цель третьего шага — обоснование технологических платформ путем их соотнесения с использующими бизнес-функциями, формирование таблицы платформы-приложения, таблицы платформы-бизнес-функции.

На четвертом шаге производится подготовка, распространение и анализ отчета по технической архитектуре.

Разработка плана реализации

Этап включает следующие основные шаги:

формирование последовательности реализации приложений;
оценка трудозатрат и ресурсов, построение плана;
оценка стоимости и достоинств плана;
определение факторов успеха и рекомендаций по их достижению.

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

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

Остальные шаги этапа традиционны для задачи планирования и здесь не рассматриваются.

Заключительное планирование

На этом этапе осуществляется подготовка окончательного отчета по ЕА, подготовка и проведение презентации.

Переход к реализации

Основными шагами этапа являются:

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

Все эти шаги являются достаточно традиционными и не представляют интереса в рамках настоящей статьи.

Системная архитектура и ее место в архитектуре предприятия. Системный архитектор: обучение, должностная инструкция и отзывы

Введение

Точки наблюдения

Уровни абстракции

Модели и диаграммы

Энциклопедичный YouTube

Субтитры

История возникновения понятия

Сопутствующие понятия

Виды архитектуры

Логическая архитектура

Физическая архитектура

Архитектурное описание

Концептуальный подход

Типы групп описаний архитектуры

Функциональная группа описаний

Логическая группа описаний

Базовые понятия

Системная архитектура

Взаимосвязи системной архитектуры и бизнес-архитектуры

Жизненный цикл системной архитектуры

Начальное документирование

Использование

Проектирование

Миграция

Состав базы знаний по системной архитектуре

Принципы построения

Основные решения

Требования и стандарты

Прикладная архитектура

Техническая архитектура

Сетевая архитектура

Архитектура платформ

Архитектура данных

План миграции

Заключение

Инициация планирования

Предварительное бизнес-моделирование

Формирование снимка предприятия

Описание текущих систем и технологий

Формирование архитектуры данных

Формирование архитектуры приложений

Формирование технической архитектуры

Разработка плана реализации

Заключительное планирование

Переход к реализации

Способы слияния и поглощения компаний

Алексей Ерёменко - младший политрук