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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В самом общем виде, в соответствии с определениями Gartner [3.6], [3.7], архитектура – это:

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

Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.

Еще несколько определений:

• «Архитектура – это инвестиция в стандарты процессов, технологий и интерфейсов в целях улучшения возможностей организаций и уменьшения стоимости разработки и сопровождения информационных систем. Преимущества инвестиций в архитектуру распространяются на несколько проектов сразу, но не все эти проекты могут быть известны в момент разработки архитектуры»;
• «Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий» (Giga Group) [3.8];

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

Рассмотрим теперь более подробно, какие отдельные понятия в рамках представления об «архитектуре» существуют, и как они связаны между собой. Можно выделить, по крайней мере, 3 различных «измерения» в данном континууме определений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пространства имён

Действия на странице

Архитектура предприятия (business architecture, enterprise architecture) — план предприятия (enterprise), который обеспечивает общее понимание организации (основные организационные и логистические решения), стратегические цели и тактические требования.

Содержание

Терминология

• «Предприятие» является бизнес ассоциацией, состоящей из признанной совокупности взаимодействующих бизнес функций. Она способна работать как независимая, отдельная организация. Согласно такому определению, могут существовать предприятия в пределах предприятий. Например, организационная единица внутри общей корпоративной организации может быть рассмотрена как предприятие при наличии возможности независимого функционирования. Предприятие можно также рассматривать как «Расширенное предприятие (Extended Enterprise)»; это означает, что масштаб архитектуры предприятия может также включать взаимосвязи с внешними организациями. Такими как: поставщики, бизнес-партнеры и клиенты.
• «Архитектура» обеспечивает базовую концепцию. Она определяет и описывает платформу, необходимую предприятию для достижения своих задач и своего видения. Ее можно определить как: совокупность принципов, ориентиров, правил, моделей, стандартов и процессов, соответствующих требованиям бизнес стратегии и информации, направляющих выбор, создание и внедрение решений для будущих направлений бизнеса.

Моделирование процессов в организации

Задача моделирования «процессов» чаще всего появляется в следующих случаях:

• «Чтобы было» — для отчетности инвесторам, в том числе формального доклада Совету Директоров, или для покупки сертификата серии ISO 9000.
• Налаживание хода «регулярного менеджмента», когда делается попытка формализовать текущий оргбардак с целью провести хоть какую-то реорганизацию — т.е. для помощи менеджерам в принятии решений.
• При запуске нового сервисного продукта для договоренностей о том, как будет происходить работа множества разных служб в сложном «операционном дне»: кто что кому передаёт, и во сколько, чтобы успеть для какого-нибудь важного производственного цикла.
• Создание какой-то информационной системы. Быстро выясняется, что система живёт не в вакууме, а в организации, и требуется отмоделировать организацию, что и делают через «процессы».

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

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

Языки моделирования

• ArchiMate (ссылки) и архитектурный язык OpenGroup ArchiMate 2.0.

Критика архитектурных подходов

Опыт показывает, что все архитектурные подходы не слишком адекватны:

• группы описаний заставляют описать много лишнего, но не выявляют сущностного
• языки это сущностное не позволяют выражать

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

1. Органиграмма как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то «органиграмма» оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
2. Структуры целей организации: например, Business motivation model (OMG BMM), или голдраттовское Strategic & Tactics Tree (S&TT).
3. Правила работы (Business rules), например OMG SBVR. «Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке».
4. Процессы
   • Процессы моделируется как цепочка поручений работы (напр., от запроса клиента до выполнения заказа), которая обязательно возращается (будь это внутренний «заказ», или «внешний», по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать «организационную сущность»: кто что кому поручает, саму «организованность людей». Представителем такого подхода к «процессам» является DEMO (Design & Engineering Methodology for Organizations).
   • Процессы документируются. Поскольку организация должна выполнять разные функции, эти функции нужно задокументировать. Этим занимаются главным образом люди, проникнувшиеся ISO 9000 и тамошнего понимания «процессов» как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции — это не работы («конструкция»), это функции, и об этом забывают. На диаграммах IDEF0 (наиболее часто используемый стандарт изображения функций, раньше это называлось SADT) в верхнем левом углу рисуется не «самый первый шаг», а «самая важная функция на листе». То есть «процесса», как развертки времени, в IDEF0 нет.
   • Документирование процесса во времени. Процесс, как развертка во времени из выполняемых шагов, или workflow («ход работ») это и есть BPM (business process management) — IDEF3 в наиболее древней нотации, в России хорошо известна нотация EPC (event-driven process chain) из ARIS, а главным современным стандартом является OMG BPMN 2.0, который поддерживают все «движки процессов». Каждую неделю очередная фирма заявляет о поддержке BPMN 2.0 моделирования, и компьютерного исполнения процессов, отмоделированных в BPMN 2.0.
   • Практики жизненного цикла (по-английски это иногда processes, а иногда practices). Развертка во времени тут — это сам жизненный цикл (life cycle), понимаемый как «последовательность стадий», где каждая стадия соответствует примерной одинаковости состояния системы в ходе работ по ее инженерии (замысел, проектирование, сооружение, эксплуатация и т.д. — хоть спички, хоть организации, хоть космодрома). А вот в ходе стадий выполняются те или иные практики, причем подробно не рассказывается, как их делать «шаг за шагом», зато указываются руководства, требования к квалификации сотрудников, выполняющих эти практики, нужный инструментарий, используемые языки и нотации представления информации. Именно из описания жизненного цикла можно узнать, используются ли в работе «итерации», или никаких итераций нет, и «возврат на доработку» — это ЧП. Стандарты такого описания — OMG SPEM, ISO 24744 и вновь разрабатываемый подход SEMAT. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
5. Проекты.