Принципы архитектуры предприятия

Элементы Архитектуры предприятия. Бизнес-архитектура и архитектура информации

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

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

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

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

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

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

• Миссия и видение.
• Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий.
• Цели, задачи и стратегии.
• Архитектура информационных технологий.
• Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов.
• ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции.
• Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.
• Руководства или рекомендации (gu >

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

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

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

Важным представляется следующее замечание, сформулированное в архитектурной методике META Group, которое касается роли принципов и моделей в описании архитектуры (более подробно об этом см. в «Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF» ). Можно сказать, что существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия: существенная, возможно, даже большая часть специалистов и компаний считает, что основой архитектуры являются принципы, а другая часть придерживается точки зрения, что основой архитектуры является процесс создания моделей. META Group полагает, что при описании сегодняшней, существующей архитектуры (архитектуры «как есть») необходимо в большей степени руководствоваться декларациями принципов, на основе которой она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры.

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

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

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

Эволюция содержания архитектуры предприятия по мере ее разработки и развития условно показана на рис. 5.4.

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

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

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

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

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

Основу управления и контроля архитектурного процесса, как правило, составляет набор руководящих принципов. Многие аналитики выделяют следующий набор принципов:

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

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

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

· Должны быть разработаны и поддерживаться в актуальном состоянии стандарты, правила и политики. Все проекты должны контролироваться на соответствие стандартам.

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

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

Правильно построенный процесс контроля и управления может существенно повлиять на проект на начальных этапах его функционирования:

· Начало проекта. На этом этапе проекту предоставляются документы с описанием архитектурных шаблонов и принципы построения информационных систем.

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

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

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

Архитектурные принципы построения Корпоративных Информационных Систем (КИС) — это набор основных правил построения систем обеспечивающих получение, обработку и хранение информации в компании.

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

Принципы построения приложений:

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

· Предпочтение отдается промышленным информационным системам от крупных поставщиков.

· Информационные системы отвечают принципам SOA.

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

· Информационные системы должны быть открытыми, гибкими, легко масштабируемыми.

· Информационные системы должны обеспечивать простоту интеграции.

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

Принципы организации данных:

· Автономность (независимость) данных.

· Используется единое централизованное определение элементов данных

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

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

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

Принципы построения ИТ инфраструктуры:

· Техническая инфраструктура является масштабируемой и расширяемой

· Инфраструктура является простой в эксплуатации и сопровождении

· Инфраструктура является адекватной потребностям приложений и бизнеса

· Инфраструктура строится в строгом соответствии корпоративным стандартам

· Стандартизация всех программно-аппаратных средств компании

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

Методика построения архитектуры предприятия при интеграции информационных систем

Ольга Рябчикова
Инженер АО ИК «АСЭ».

Данная статья включает основные понятия по теме «архитектура предприятий», а также анализ популярных методик, предназначенных для описания таких архитектур, с выявлением наиболее подходящей модели при создании такого комплексного решения, как ESB (enterprise service bus) — корпоративной интеграционной шины [1] информационных систем компаний, занимающихся проектированием и сооружением сложных инженерных объектов.

Введение

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

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

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

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

Архитектура предприятия

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

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

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

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

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

• методика TOGAF;
• методика Gartner;
• методика META Group.

Методика TOGAF

Методика TOGAF является описанием архитектуры предприятия, которая предлагает способы и подходы для выстраивания, планирования, применения IT­архитектуры предприятия и, впоследствии, управления ею. TOGAF принимает, но не строго придерживается определения ISO/IEC 42010:2007. В TOGAF термин «архитектура» имеет два значения, в зависимости от контекста:

1. Формальное описание системы или детальный план системы на уровне ее компонентов для руководства ее реализацией.
2. Структура компонентов, их взаимосвязь, а также принципы и руководящие указания по их разработке и эволюции во времени [6].

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

1. Архитектура бизнеса.
2. Архитектура приложений.
3. Архитектура данных.
4. Архитектура технологии.

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

Методика TOGAF включает два направления:

1. Методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.
2. Базовая архитектура (Foundation Architecture).

Методика ADM включает несколько фаз, которые представлены на рис. 1.

Рис. 1. Методика ADM TOGAF

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

Концепция Базовой архитектуры основывается на иерархии архитектур, а именно:

• архитектуры общих систем;
• отраслевой архитектуры;
• архитектуры организации [5].

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

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

Методика Gartner

Компания Gartner трактует понятие «архитектура предприятия» как процесс перевода видения и стратегии бизнеса в эффективное изменение компании посредством создания, обсуждения и улучшений ключевых требований, принципов и моделей, которые описывают будущее состояние компании и делают возможным ее развитие [7].

Общая идея Gartner включает создание «идеальной» картинки будущего в бизнес­представлении и, на ее основе, определение изменений архитектуры (в приоритетном порядке) для достижения конечной цели. Цель данной архитектуры предприятия — стратегия, а не ее техническая реализация.

Суть методики Gartner — создание процесса, который позволит развивать архитектуру в соответствии с высокоуровневой архитектурой бизнес­стратегии. Она образует только общее видение системы и не определяет ни формата, ни языка для описания архитектуры.

Методика META Group

Данная методика рассматривает архитектуру предприятия в интеграции с другими процессами, к примеру с процессом управления корпоративными IT­программами и проектами и процессом выработки стратегии и планирования.

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

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

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

Сравнительный анализ

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

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

Из таблицы соответствия явно видно преимущество методики TOGAF. Как же выглядит применение методики на реальном проекте?

Таблица сравнения методик

Критерий/Методика

Методика
TOGAF

Методика
Gartner

Методика
Meta Group

Возможность описания различных структурных элементов

Описание процесса создания архитектуры предприятия

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

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

Визуальное схематичное отображение архитектуры предприятия

Восприятие архитектуры предприятия любыми специалистами

Доступность методики (ее инструментов и сервисов)

Рекомендации по управлению архитектурой

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

Рис. 2. Применение Archimate при интеграции двух программных комплексов

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

Заключение

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