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

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

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

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

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

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

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

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

В основе архитектуры предприятия заложен «Архитектурный взгляд» на системы, определенный в стандарте ANSI/IEEE 1471, как «фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии».

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

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

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

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

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

При этом архитектура предприятия неразрывно связана с основными рабочими процессами:

· стратегия и планирование на уровне предприятия;

· управление корпоративными проектами.

Рисунок 1.1. Взаимосвязь бизнеса и ИТ

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

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

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

Рисунок 1.2. Управление портфелем ИТ.

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

· максимизация ценности портфеля;

· синхронизация ИТ - портфеля с требованиями бизнеса;

· поиск оптимального баланса между риском и потенциальной отдачей от ИТ - портфеля.

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

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

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

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

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

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

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

Рисунок 1.3. Контекст и уровни абстракции архитектуры предприятия.

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

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

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

· Уровень контекста (почему?) ориентирован в первую очередь на руководство и обосновывает необходимость проектов.

· Концептуальный уровень (что?) определяет общие требования к проекту и возможные варианты его реализации.

· Логический уровень (как?) описывает способ реализации данного проекта.

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

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

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

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

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

Рисунок 1.4. Эволюция организационных принципов.

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

Текущая архитектура (Current architecture) - описывает существующее состояние архитектуры предприятия. Называется также архитектурой “как есть” (AS-IS) или базовым состоянием существующей архитектуры.

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

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

Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM(управление конфигурацией - Configuration Management). Для упрощения работы по разработке текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией.

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

Целевую архитектуру можно назвать идеальной моделью предприятия, в основу которой заложены:

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

· информация о выявленных «узких местах» и путях их устранения;

· анализ технологических тенденций и среды бизнес деятельности предприятия.

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

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

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

Рисунок 1.5. Основные слои архитектуры предприятия

· Стратегические цели и задачи предприятия.

· Бизнес – архитектура предприятия.

· Архитектура информационных технологий (ИТ архитектура предприятия).

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

· Информационную архитектуру (Enterprise Information Architecture).

· Архитектуру прикладных решений (Enterprise Solution Architecture).

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

Сталкиваясь с технологическими новинками, бизнес в лице владельца решает две задачи:

• Что может дать технологическая новинка бизнесу?
• Как и когда (при каких условиях) следует ее использовать?

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

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

Концепция архитектуры систем проста. Архитектура – это взаимосвязь структур, описывающих объект. Структура, в свою очередь, – это взаимосвязь однородных элементов, составляющих объект. Так что архитектура есть у каждого предприятия. Другими словами, АП – это писаные и неписаные правила появления, изменения, удаления и взаимодействия составляющих элементов предприятия. Получается, что и описание АП есть практически у каждого предприятия. За исключением, естественно, «неписаных правил». В чем же тогда особенный интерес к использованию IT для описания АП именно сейчас? Назову три особенности:

1) Компьютерные технологии сами по себе стали элементами АП. Их много и связей между ними достаточно много;

2) Компьютерные технологии связаны со многими другими элементами АП;

3) Изменяются компьютерные технологии очень быстро, следовательно – быстро изменяется и АП.

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

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

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

Как формировать описание архитектуры предприятия

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

Упрощенно, процесс описания архитектуры предприятия можно подразделить на пять этапов:

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

Этапы №2-5 повторяются регулярно.

Циклы формирования описания архитектуры предприятия

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

Все элементы АП описать невозможно, да и не нужно. В каждом цикле следует в первую очередь выбирать те элементы АП, информацию о которых вы считаете недостаточной. Большую помощь в выборе элементов может оказать знакомство с многочисленными моделями и методологиями построения архитектуры предприятия: TOGAF, Модель Захмана, DoDAF и другими.

1) Не пытайтесь сразу описать сложные элементы архитектуры полностью. Выбранная модель представления АП должна позволять фиксировать неполноту описания. Например, лучше не оставлять значения описываемых элементов пустыми. Если какая-то из характеристик отсутствует – просто указывайте «N/A» (not applicable). Если значение характеристики необходимо выяснить – пишите «TBD» (to be defined). Можете расширить эту классификацию собственными категориями: «будет выявлено на этапе Х», «неважно на настоящий момент», «полное описание см. в системе Y» и т. п. Когда вы понимаете, какой именно информацией не располагаете и тем более почему – это тоже информация для принятия решений.

2) Отделите описание АП от ее проектирования (разработки). Описание АП – это документирование всех осуществленных изменений на предприятии согласно решениям, положенным в основу модели. Проектирование АП – подготовка любых изменений на предприятия. Эти две активности используют разные методы. Общее у них только документирование. Технически, можно объединить в общем описании АП и описание «как есть» (as is) и описания «как будет» (to be). Но необходимо учитывать, что это разные задачи, разные компетенции, разные проекты.

3) Не назначайте ответственным за описание АП «главного архитектора». И вообще, не ищите главного архитектора. Архитекторов много: архитектор бизнес-процессов, архитектор данных, архитектор информационной безопасности и некоторые другие. Все, кто уполномочен принимать решения по формированию или изменению каких-либо структур или процессов на предприятии являются архитекторами. И все они – ответственные за соответствующие элементы АП. Иерархию архитекторов, естественно, возглавляет владелец бизнеса. Задача описания заключается в подготовке консолидации данных. Ответственный за описание АП не должен проектировать проведение каких-либо изменений на предприятии или в IT. Единственное требование к его профессиональным способностям – это разработка модели АП и организация работ по ее наполнению.

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

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

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

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

7) Начинайте задумываться об описании АП тогда, когда почувствуете неуверенность в правильной расстановке приоритетов своих задач.

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

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

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

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

Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!

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

Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет - «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.

Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?

Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ - требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ - это программный код.

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

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

Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, - для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это - отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.

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

Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, - как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.

Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?

Собственно, все. С наступающим, и до новых встреч!

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

Поделитесь работой в социальных сетях

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

Введение

1.3. Слои в архитектуре

Список литературы

Введение

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

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

1. Теоретические аспекты архитектуры предприятия

1.1. Ключевые элементы архитектуры предприятия

Управление архитектурой предприятия (Enterprise Architecture) создает основу для синхронизации объектов внутри предприятия и в то же время обеспечивает их непрерывное изменение для целей оптимизации бизнеса.

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

С одной стороны, детальность создаваемого описания означает более глубокую проработку, а с другой – появляются излишние трудозатраты, как на создание самого описания, так и на поддержку его в актуальном состоянии. Как говорится, «лучшее враг хорошего», и поэтому слишком подробное описание элементов архитектуры не приносит пользы. На этом этапе важно установить ключевые элементы архитектуры предприятия из всех возможных и сосредоточиться именно на их описании и анализе.

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

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

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

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

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

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

Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнес-архитектуры и ИТ-архитектуры являются требования к информационной системе. Фактически модели требований – это целевой функционал ИТ-решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 г. TeleManagement Forum и содержит следующие модели:

1. модель операций телекоммуникационной компании eTOM (Enhanced Telecom Operations Map – eTOM);
2. информационная модель телекоммуникационного предприятия (Enterprise-wide Information Framework Shared Information and Data Model – SID);
3. структура приложений телекоммуникационной компании (Applications Framework – Telecom Applications Map – TAM ).

1.2. Модели и инструменты архитектуры приложений

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

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

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

1. Имеющийся портфель прикладных систем. Это каталог имеющихся приложений и компонент, который отражает их связи с поддерживаемыми ими бизнес-процессами, интерфейсы с другими системами, используемую и требуемую информацию, используемые инфраструктурные шаблоны. Чтобы быть реально полезным инструментом, он также должен помогать в идентификации тех элементов портфеля, которые можно использовать повторно и многократно в рамках предприятия, и стимулировать такое повторное использование.
2. Планируемый портфель прикладных систем. Представляет функциональность, которая требуется для обеспечения желаемого состояния бизнес-архитектуры и архитектуры информации предприятия.
3. План миграции. Процесс перехода от текущего к будущему портфелю прикладных систем в рамках ИТ-проектов. Проекты также могут объединяться в портфели проектов. Первым шагом в планировании портфеля прикладных систем является оценка текущего состояния портфеля и того, насколько он соответствует потребностям организации со стратегической и технологической точек зрения, т.е. с точки зрения задач, стратегий бизнеса и с точки зрения технического состояния и стратегий использования технологий на предприятии. Соответствие бизнес-стратегиям оценивается на основе вклада прикладных систем в достижение бизнес результатов, что определяется бизнес-архитектурой предприятия. Технологическое соответствие оценивается на основе анализа того, насколько прикладные системы соответствуют принципам и технологическим стандартам, принятым в технологической архитектуре предприятия. Существуют различные способы оценки портфеля и различные классификации прикладных систем предприятия. Одной из возможных моделей оценки портфеля прикладных систем является оценка их по двум критериям – ценность с точки зрения бизнеса и техническое состояние. Оценка портфеля служит отправной точкой в идентификации проблемных областей и возможностей для лучшего удовлетворения потребностей бизнеса и принятия решения об инвестициях в новые системы или обновление существующих. В результате такой оценки прикладные системы относятся к одной из четырех возможных категорий:
   1. системам грозит вывод из эксплуатации (замена) или консолидация;
   2. системы, требующие переоценки или перепозиционирования;
   3. системы, требующие обновления;
   4. системы, требующие сопровождения и развития.

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

1.3. Слои в архитектуре

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

Слои легко формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n – это компонент или набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.

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

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

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

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

Схема архитектурных слоев обладает и определенными недостатками:

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

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

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

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

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

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

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

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

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

Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия.

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

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

В архитектуре предприятия следует выделять следующие слои:

1. Фронт-офис (Front-Office)

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

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

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

1. Мидл-офис (Middle-office)

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

Примеры подразделений мидл-офиса:

Подразделение проверки заемщиков в службе безопасности,

Подразделение управления рисками.

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

Примеры информационных систем мидл-офиса:

Система ведения позиционного учета,

Система проверки заемщика в бюро кредитных историй,

Система расчета скорингового балла по кредитной заявке.

1. Бэк-Офис (Back-Office)

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

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

1. Учёт (Accounting)

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

1. Информационное хранилище (DWH)
2. Отчётность (Reporting)

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

Примеры систем отчётности:

Система управленческой отчётности,

Система аналитической отчётности,

Система ключевых показателей эффективности подразделений предприятия,

Система формирования показателей для расчёта скорингового балла по кредитной заявке.

Список литературы

1. Васильев Р. Б., Калянов Г. Н., Левочкин Г. А., Лукинова О. В. Стратегическое управление информационными системами; Интернет-университет информационных технологий, Бином. Лаборатория знаний - Москва, 2013 . - 512 c.
2. Гриценко Ю. Б. Архитектура предприятия: Учебное пособие / Гриценко Ю. Б. – 2011. 256 с.
3. Данилин А.В., СлюсаренкоА.И., Учебный курс – Архитектура предприятия [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/itmngt/entarc/
4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. Учебное пособие: М.: Финансы и статистика, 2006.

PAGE 17

Другие похожие работы, которые могут вас заинтересовать.вшм>
803.		Архитектура гостиничного предприятия	36.04 KB
	Архитектурные аспекты построения и размещения гостиниц. Роль интерьера и дизайна гостиниц на гостиничное предложение. Введение Специфика гостиниц заключается в многообразии функций этих объектов. Благоприятные условия жизнедеятельности человека в гостиницах обеспечиваются благодаря созданию комфорта как в самом здании гостиницы так и на территории прилегающей к ней.
17390.		Архитектура Великого Новгорода	324.25 KB
	Преобладает точка зрения что старый город это так называемое Городище находящееся на правом берегу Волхова в двух километрах от современного города. Чтобы более глубоко познакомится с архитектурой этого города была работы выбрана тема Архитектура Новгорода XI-XV веков. Техника подобных произведений заключалась в том что по зачерненным медным листам резцом наносился рисунок и в его канавки вплавлялась золотая проволока. Ее можно отнести к древнейшим: доска на которой она написана очень старая по ряду признаков и характеру...
19556.		Сталинский вертикализм и архитектура	24.72 KB
	Для того чтобы уяснить специфику собственно советского пути и формообразования и содержания советской архитектуры нужно изучать ограничения и предписания которые накладывались общегосударственной организацией профессиональной деятельности на образ мыслей конкретных мастеров. и с другой - планы квартир сталинского ампира содержащих террасы гостиные комнаты для домработниц и проч.: Неоклассицизм неоклассика термин принятый в советском искусствознании для обозначения различных по социальной направленности и идеологическому...
17255.		Храмовая архитектура Москвы	595.99 KB
	Яркая окраска кирпичных стен церкви Троицы расчлененных нарядной декоративной отделкой из белого резного камня и цветных поливных изразцов покрытие из белого немецкого железа золотые кресты на зеленых черепичных главках все вместе взятое создавало неотразимое впечатление...
13405.		Архитектура Старовавилонского царства	528.04 KB
	Центром ее был город Вавилон Бабили означает Ворота бога цари которого во II тыс. Расцвет Старовавилонского царства пришелся на время правления шестого царя I Вавилонской династии Хаммурапи. При нем Вавилон из небольшого города превратился в крупнейший экономический политический и культурный центр Передней Азии.
7046.		Архитектура и структура ПК. Принцип фон Неймана	9.14 KB
	ПК называют относительно недорогой универсальный микрокомпьютер, рассчитанный на одного пользователя. Современные ПК проектируются на основе принципа открытой архитектуры.
6695.		Архитектура базы данных. Физическая и логическая независимость	106.36 KB
	Там приводятся следующие определения банка данных базы данных и СУБД: Банк данных БнД это система специальным образом организованных данных баз данных программных технических языковых организационно-методических средств предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных. База данных БД именованная совокупность данных отражающая состояние объектов и их отношений в рассматриваемой предметной области. Система управления базами данных СУБД совокупность языковых и...
18392.		Разработка учебно-методического комплекса по дисциплине «Архитектура ЭВМ»	606.23 KB
	Потом круг пользователей расширился в первую очередь за счет ученых использовавших вычислительные машины для проведения машинных экспериментов. Электронным учебником называется продукт образовательного характера который может быть воспроизведен только с помощью средств информатики в том числе и компьютера соответствующий утвержденной программе обучения или программе разработанной автором для предложенного курса и имеющий принципиально новые черты по сравнению с обычным учебником.п Электронный учебник может быть предназначен для...
9225.		АРХИТЕКТУРА И ЭЛЕМЕНТНАЯ БАЗА ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ ЛА	150.96 KB
	Наступившие XXI столетие и третье тысячелетие все настойчивее ставят вопрос: какие летательные аппараты (ЛА) истребительной авиации обеспечат превосходство в воздухе? На поставленный вопрос следует однозначный ответ - ими станут истребители следующего, 5-го поколения, реактивной эры авиации. Провести четкую грань между поколениями ЛА трудно и не всегда возможно. Да и сама смена поколений процесс довольно медленный.
21769.		Процессоры Intel, архитектура процессоров, чипсеты и их характеристики	95.27 KB
	Центральный процессор (Микропроцессор, ЦП) - часть аппаратного обеспечения компьютера, отвечающая за выполнение арифметических операций, заданных программами, и координирующая работу всех устройств компьютера. Процессор представляет собой специально выращенный полупроводниковый кристалл, на котором располагаются транзисторы

Виктор Галактионов, 20.05.2002
Журнал "Директор ИС", #05, 2002 год // Издательство "Открытые Системы" (http://www.osp.ru/)

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

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

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

Известно, что бизнес любой современной компании все больше и больше становится зависим от информационных технологий. Развитие отдельных направлений бизнеса, например развитие «карточного бизнеса» в банках, стало возможным исключительно благодаря появлению современных ИТ. Конечно, это справедливо и для предприятий других отраслей. Потому можно надеяться, что излагаемый опыт без значительных усилий по адаптации может быть использован в бизнесе любой другой, небанковской компании.
Особенности сегодняшнего уровня развития банковских информационных технологий заключается в том, что во многих банках, которые смогли сохранить свой бизнес после кризиса 1998 года и сегодня продолжают его активно развивать и наращивать, высокотехнологичные банковские решения внедряются на фоне продолжающейся эксплуатации программных систем и комплексов предыдущих поколений, зачастую морально устаревших. С другой стороны, остановка банковского бизнеса даже на несколько часов, тем более остановка на один или несколько дней для вывода из эксплуатации устаревшего программного обеспечения и ввода в эксплуатацию нового, в большинстве случаев будет равносильна утрате бизнеса. В этой ситуации в каждый момент времени необходимо иметь четкое представление о текущем статусе всех внедряемых и эксплуатируемых информационных систем, а также не менее четкое понимание их дальнейшего развития с учетом перспектив развития банка, его архитектуры как архитектуры предприятия . (В англоязычной литературе — методиках, статьях, стандартах — этому соответствует термин enterprise architecture .)
Следует отметить, что архитектура предприятия существует независимо как от нашего сознания, так и от размера этого предприятия — будь то глобальная корпорация, небольшой завод, малое торговое предприятие и т. п. У малого предприятия архитектура есть так же, как и у крупного, при этом они не слишком сильно различаются по составу компонентов. Однако одни руководители это понимают и могут себе позволить уделять внимание всем аспектам устройства своего же предприятия (это, как правило, руководители крупных компаний), а другие — нет. Иное дело, что у малого предприятия могут быть всего два-три продукта, миссия и стратегия в явной форме не зафиксированы (эта беда, кстати, встречается часто и в крупных компаниях), количество сотрудников составляет 30 человек и в производстве используется два компьютера с MS Word 97. Но и в таком случае это все и составляет архитектуру данного предприятия.
В статье представлен достаточно развернутый и одновременно прагматичный подход к организации работ по анализу архитектуры предприятия в целом и планированию системной архитектуры, в том числе к ее документированию. Основными целями документирования знаний о бизнесе (разработки архитектуры предприятия) являются обеспечение сохранности инвестиций в бизнес и прозрачности бизнеса на всех уровнях.
Прозрачность бизнеса начинается с прозрачности понимания архитектуры предприятия, с четкого разделения ее на три взаимозависимых уровня: стратегический уровень, уровень бизнес-архитектуры, уровень системной архитектуры. Системная архитектура определяется бизнес-архитектурой, и ее проектирование может осуществляться только на основании бизнес-архитектуры, которая в свою очередь зависит от стратегии предприятия. Этот подход позволяет, на наш взгляд, не только правильно организовать сами работы и произвести корректное разделение функций и ответственности бизнес-архитектора («бизнес-девелопера»), отвечающего за развитие бизнеса, то есть бизнес-архитектуры предприятия, и системного архитектора, но и, самое главное, выстраивать сбалансированную архитектуру предприятия, адекватно соответствующую его миссии и стратегии.
В начале статьи приведены основные определения. Затем рассмотрен состав и содержание системной архитектуры, проанализированы взаимосвязи сущностей бизнес-архитектуры и системной архитектуры. Достаточно детально рассмотрены фазы и участники жизненного цикла системной архитектуры, в частности функции участников. Наконец, в сокращенном виде представлена структура знаний, лежащих в основе системной архитектуры, и сделаны заключительные выводы.

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

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

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

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

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

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

Рис. 2.

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

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

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

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

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

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

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

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

Рис. 3.

Компоненты системной архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6.

Сущности и взаимосвязи двух архитектур

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

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

Рис. 7.

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

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

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

Рис. 8.

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

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

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

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

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

Таблица 1.

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

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

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

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

Таблица 2.

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

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

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

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

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

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

Таблица 3.

Миграция

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

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

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

Таблица 4.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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