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

Это частный случай проектирования программного обеспечения.

Чем занимается

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

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

Должностные задачи

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

Архитектор осуществляет:

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

В обязанности также входит сама разработка проекта.

Среди обязательных пунктов:

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

Документация

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

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

Ответственность

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

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

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

Где необходимы

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

Обучение

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

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

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

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

Заработная плата

Данная позиция - довольно редко встречается даже среди специалистов узкой сферы интернет-технологий. Исходя из этого, оплата труда начинается от 70 000 р. в регионах, а крупных городах, таких как Екатеринбург, Санкт-Петербург, Москва, стартует от 130 000 р.

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

• Образование должно быть только высшим (ИТ или технического направления).
• Знание современных методологий, ПО - обязательно.
• Широкий кругозор и начитанность в сфере технологий, а также умение применять отдельные элементы к своей системе - необходимый навык.
• Английский - как минимум Intermediate level, что позволяет читать документацию и инструкции к оборудованию на языке оригинала.
• Опыт работы по специальности - от трех лет.

Стоит отметить, что даже для специалиста без опыта работы заработные платы в Москве - от 80 000 р.

Описание сотрудника

Многочисленные исследования, проводимые разнообразными карьерными порталами, выяснили, что:

• 30 - 40 лет - средний возраст сотрудника в должности архитектора. Таких работников - почти половина, 46%.
• Высшее образования есть у 92%, а 75% всех сотрудников на данной должности имеют управленческий опыт и проходили дополнительное обучение.
• Английский язык на уровне чтения документов и инструкций знает 52%, а свободно владеет на разговорном уровне - более 35%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предварительная бизнес-модель идентифицирует функции, дает их описания и идентифицирует организационные единицы — исполнителей функций. По оценкам ряда экспертов этап требует 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%).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лекция 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 в качестве основного инструмента управления информационными ресурсами банка.

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