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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

"Архитектура системы: единая фундаментальная структура системы, описанная в терминах поведения, ограничений, процессов, интерфейсов и элементов системы".
[базовое определение, одобренное INCOSE Systems Architecture Working Group на конференции INCOSE 1996 в Бостоне (Массачусетс) 8 июля 1996 года]

"Архитектура системы описывает основные физические свойства, стиль, структуру, взаимодействия и предназначение системы".
[Process for System Architecture and Requirements Engineering , Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

"Архитектура - это набор концепций и правил, характеризующих структуру, семантическое поведение и взаимосвязь между компонентами системы; план конструирования чего-либо. В состав архитектуры входят элементы, образующие конструкцию, отношения между ними, ограничения на эти отношения, описание отдельных компонентов конструкции, а также описание конструкции в целом".
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2: Information Technology - Open Distributed Processing - Reference Model: Foundations, as the source]

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

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

Хотя эти определения оперируют различными терминами и охватывают различные наборы аспектов, они во многом пересекаются. Все определения сходятся в том, что архитектура описывает следующие компоненты:

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

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

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

Точка наблюдения (в контексты системы) - это "форма абстракции, которая достигается с помощью определенного набора архитектурных концепций и правил структурирования для того, чтобы сфокусироваться на определенных аспектах системы" . В следующей таблице приведены примеры точек наблюдения для различных аспектов системы. Эти точки наблюдения соответствуют стандарту ISO/IEC 10746-1: Information technology - Open Distributed Processing - Reference Model: Overview.

Точка наблюдения Аспект Сфера
Исполнитель Исполнителя интересуют роли и сферы ответственности организации и сотрудников (и установленные для них правила). Деятельность исполнителей, взаимодействие пользователей с системой. Человеческий фактор и производительность труда.
Информация Виды информации, обрабатываемой системой, и ограничения на использование и интерпретацию этой информации. Целостность информации, ограничения на объем.
Доступность и актуальность информации.
Логика Декомпозиция системы на набор подсистем, взаимодействующих через интерфейсы и обеспечивающих выполнение функций системы. Поведение системы отвечает требованиям.
Система поддерживает расширение, адаптацию, обслуживание.
Активы допускают повторное использование.
Комплектация и физические характеристики Инфраструктура, необходимая для обеспечения нормальной работоспособности системы. Соответствие физических характеристик системы предъявляемым к ней функциональным и нефункциональным требованиям.
Процесс Параллелизм, расширяемость, производительность, пропускная способность, надежность. Соответствие системы требованиям к времени отклика, пропускной способности и отказоустойчивости.

Общие точки наблюдения.

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

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

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

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

Архитектурные уровни RUP

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

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

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

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

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

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

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

Уровень модели Точки наблюдения
Исполнитель Логика Информация Комплектация и физические характеристики Процесс
Контекст Организационное представление UML Диаграмма контекста системы Представление данных организации Представление локальности организации Представление бизнес-процессов
Анализ Общее представление исполнителей Представление подсистем Представление данных системы Представление локальности системы Представление процессов системы
Эскиз Представление исполнителей Представления классов подсистем

Представления компонентов программного обеспечения

 Схема данных системы Представление узлов дескрипторов Подробное представление процессов
Реализация Инструкции и спецификации ролей исполнителей Конфигурации: диаграммы развертывания с компонентами программного и аппаратного обеспечения системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обучение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимосвязь этих понятий иллюстрируется на рисунке 3.5 .


Рис. 3.5.

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

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

В дальнейшем мы будем использовать термин " архитектура ", который, в зависимости от контекста, может означать как существующую реальность, так и соответствующее описание.

Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.6 .


Рис. 3.6.

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

Однако этот стандарт не определяет структуру собственно архитектуры предприятия. Например, говорится о том, что необходимо иметь различные представления архитектуры , но при этом не указывается, какие это должны быть представления. Подробную информацию об этом стандарте описания архитектуры можно получить по адресу http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf .

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

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

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

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

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

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



Отчетность за сотрудников

Вам также может понравиться