Архитектура предприятия Пономарев 090303 24 тема (1). Управление и контроль процесса разработки архитектуры предприятия
 Скачать 106.59 Kb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ ЛЕСОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» КАФЕДРА ИНТЕЛЛЕКТУАЛЬНЫЕ СИСТЕМЫ Дисциплина: «Архитектура предприятия» Реферат На тему: «управление и контроль процесса разработки архитектуры предприятия» Студент: Пономарев В.А. Гpуппa 09.03.03 . Екатеринбург 2021 год ОглавлениеВведение 2 Архитектура: основные определения 5 Элементы архитектуры предприятия. 12 Принципы, модели и стандарты в рамках архитектуры предприятия 15 Оценка зрелости архитектуры 21 Ссылки 28 ВведениеМногие люди, в том числе бизнес-руководители и профессионалы в своих предметных областях, считают, что они хорошо разбираются в технологиях, что на самом деле редко соответствует действительности. Для большинства высших руководителей ИТ-технологии ассоциируются с персональным компьютером, о котором они знают некоторые базовые вещи. Это, кстати, является одной из причин, почему многие из них бывают удивлены, когда им пытаются объяснить всю сложность комплекса управления ИТ. Нужен некоторый язык, который бы позволил объяснить о технологиях то, что действительно необходимо знать бизнес-руководителям. Попытки объяснять все в терминах гигабайт, сетевых протоколов и углубления в дебри ИТ приносят мало пользы. Что необходимо понимать, так это базовую структуру архитектуры ИТ и почему все элементы этой архитектуры необходимы. Современные подходы к формулированию понятия архитектуры ИТ являются попытками предоставить такой язык, понятный и полезный одновременно для бизнес-руководства и для специалистов в области ИТ. С другой стороны, представление об архитектуре предприятия имеет свои корни в дисциплине, которая получила название "системное мышление". Основным объектом изучения этой дисциплины является система, когда "целое составляет нечто большее, чем механическая сумма составляющих, т.е. система обладает свойствами, которые отсутствуют у составляющих ее элементов". Эберхард Речтин (Eberhardt Rechtin), чья цитата была только что приведена, является одним из основателей этого направления мышления. Еще одно важное замечание состоит в уточнении понятия "Предприятие". Что мы имеем в виду, когда говорим о предприятии в контексте архитектуры? На самом деле, этот термин большинство специалистов по архитектуре и соответствующие методики описания архитектуры трактуют достаточно гибко. Это может быть организация в целом или одно из ее бизнес-подразделений, или же это может быть некоторая совокупность предприятий или организационных единиц в рамках единой цепочки создания добавочной стоимости. Таким образом, под термином "Предприятие" мы здесь и далее имеем в виду формальное объединение, не обязательно связанное с коммерческой деятельностью. Это может быть и государственная организация, и общественное, в том числе неформальное, объединение участников, связанных общей целью. Согласно более общему определению, приведенному в , Предприятие "... представляет собой комплексную систему культурных, технологических и процессных компонент, организованных для достижения целей организации". То есть вы можете применять архитектурные подходы к целому предприятию, подразделению или даже к отдельной прикладной системе. Все зависит от уровня рассмотрения, степени "гранулированности" проблемы. Вы сами определяете для себя соответствующие границы рассмотрения. Архитектура предприятия является одним из инструментов организационных изменений и всего предприятия в целом с использованием ИТ, и особенно той части организации, которая отвечает за информационные технологии. Гуру в области бизнеса отмечают, что, вообще говоря, существуют два основных подхода к организационным изменениям. Первый подход связан с реорганизацией, реинжинирингом процессов, а второй – с управлением знаниями. По большому счету, архитектура предприятия – это прежде всего управление знаниями, т.е. процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности. Включение же в архитектуру предприятия представлений о бизнес-архитектуре обеспечивает связь с возможностями оптимизации бизнес-процессов. Архитектура предприятия частично затрагивает и процессы управления ИТ в организации. В этом плане она дополняет достаточно эффективные методики организации и реорганизации процессов внутри ИТ-службы, такие как ITIL, COBIT и другие. Архитектура: основные определенияМы уже отмечали, что многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы "облако неопределенности" между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач. Процесс транслирования этих целей в конкретные ИТ-системы часто носит очень неразвитый характер и ограничивается ежегодным бюджетным процессом, участие в котором представителей бизнеса и ИТ является основным способом общения и взаимодействия.  Рис. 1 "Облако неопределенности" между целями организации и информационными технологиями Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура. Бизнес-модели описывают стратегию организации, структуры управления, требования, ограничения и правила, а также основные бизнес-процессы, включая взаимосвязи и зависимости между ними. Т.е. бизнес-архитектура описывает на уровне предприятия в целом то, как реализуются основные функции организации, включая организационные и функциональные структуры, роли и ответственности. Архитектура информации определяет ключевые активы, связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая расположение, время, типы файлов и баз данных и других информационных хранилищ. Архитектура прикладных систем описывает те системы, которые и обеспечивают необходимый функционал для реализации логики бизнес-процессов организации. С точки зрения технологической архитектуры, важные модели включают описание ИТ-сервисов, которые требуются для реализации перечисленных выше трех других областей архитектуры. Причем логические модели ИТ-сервисов построены в абстрактной, технологически независимой форме и оставляют свободу для оптимального выбора конкретных технологий. Но, в конце концов, архитектура предприятия завершается физическими моделями, которые определяются технологиями, аппаратными и программными платформами, выбранными для реализации ИТ-сервисов. Термин "ИТ-архитектура" может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл одного и того же термина может быть разным. Каждый из нас, на самом деле, может достаточно быстро сформулировать интуитивное определение, которое после анализа окажется вполне применимым. Известных формальных определений архитектуры существует несколько сотен. Для этого достаточно зайти на сайт Института Проектирования Программного Обеспечения Карнеги-Меллона (SEI – Carnegie Mellon Software Engeneering Institute) www.sei.cmu.edu. Одно из самых простых (словарь Уэбстера) заключается в том, что ИТ-архитектура – это "способ, который используется для организации и интеграции компонент компьютерной системы". Более изощренное определение в хорошо знакомом программистам стиле заключается в том, что "Архитектура системы состоит из нескольких компонент, внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент". Такое рекурсивное определение удобно тем, что является достаточно общим, применимым практически к любой системе, а не обязательно только к системе, использующей информационные технологии, и при этом позволяет ограничить степень детализации на нужном уровне. Отметим, что упоминание внутренних компонент специально перенесено в конец определения – для отражения того факта, что "хорошая" архитектура позволяет обеспечить повторное использование или модернизацию/замену таких внутренних компонент без изменения внешней охватывающей системы. Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу – облегчить ее восприятие человеком.  Рис. 2. Элементы архитектуры предприятия В самом общем виде, в соответствии с определениями Gartner, архитектура – это: общий план или концепция, используемая для создания системы, такой как здание или информационная система, или "абстрактное описание системы, ее структуры, компонентов и их взаимосвязей"; семейство руководящих принципов, концепций, правил, шаблонов, интерфейсов и стандартов, используемых при построении совокупности информационных технологий предприятия. Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения. Еще несколько определений: "Архитектура – это инвестиция в стандарты процессов, технологий и интерфейсов в целях улучшения возможностей организаций и уменьшения стоимости разработки и сопровождения информационных систем. Преимущества инвестиций в архитектуру распространяются на несколько проектов сразу, но не все эти проекты могут быть известны в момент разработки архитектуры"; "Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий" (Giga Group); Архитектура ИТ и принципы ее построения, с одной стороны, зависят от общих стратегических планов, бизнес-потребностей организации, общего видения роли ИТ в деятельности организации, а с другой стороны, определяют многие аспекты, такие как принятая практика по планированию капитальных затрат, обеспечение жизненного цикла систем и т.д. Рассмотрим теперь более подробно, какие отдельные понятия в рамках представления об "архитектуре" существуют, и как они связаны между собой. Можно выделить, по крайней мере, 3 различных "измерения" в данном континууме определений: иерархия архитектур различных организационных систем; соотношения между объективной реальностью и субъективным восприятием; соотношения между общесистемной архитектурой и частными архитектурами. Точно так же, как и в строительстве, существуют различные уровни архитектуры (план города, план застройки района, планы отдельных зданий), требуется дальнейшая детализация высокоуровневых определений и классификация архитектуры бизнеса и информационных технологий на различных уровнях. Таким образом, мы можем говорить об архитектуре предприятия в целом, архитектуре уровня отдельных проектов или семейства продуктов, можем говорить об архитектуре отдельной прикладной системы. И в первом, и во втором, и в третьем случае – это все архитектуры. Вопрос заключается в декомпозиции сложных систем и в том, на каком уровне принимаются те или иные архитектурные решения. Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое "расширенное предприятие") и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо. Чуть позже мы вернемся к определению понятия архитектура предприятия. Архитектура уровня отдельных проектов определяет структуру и функции систем (бизнес и ИТ) на уровне проектов и программ (совокупностей проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем. Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках архитектуры предприятия. Архитектура прикладных систем определяет структуру и функции приложений, которые разрабатываются с целью обеспечения требуемой функциональности. Некоторые элементы этой архитектуры могут быть определены на уровне архитектуры предприятия или архитектуры отдельных проектов (в форме стандартов и руководств) в целях использования лучшей практики и соответствия принципам всей архитектуры в целом. Элементы архитектуры предприятия.Бизнес-архитектура и архитектура информации Почувствовавши себя на воле, ...они (жители города Глупова) вздумали строить башню, с таким расчетом, чтоб верхний ее конец непременно упирался в небеса. Но так как архитекторов у них не было, а плотники были неученые и не всегда трезвые, то довели башню до половины и бросили. М. Е. Салтыков-Щедрин. "История одного города" Домены (предметные области) архитектурыОбычно в составе архитектуры выделяют от четырех до семи основных представлений (предметных областей или доменов) . Эти области последовательно покрывают архитектурные аспекты, отталкиваясь от потребностей функционирования организации (бизнеса) и обеспечивая весь набор технологий для реализации конкретного решения бизнес-проблемы. Ниже перечислены представления (домены) архитектуры: Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов. Архитектура информации (данных). Определяет, какие данные необходимы для поддержания бизнес-процессов (например, модель данных), а также для обеспечения стабильности и возможности долговременного использования этих данных в прикладных системах. Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций (например, модели приложений). Технологическая архитектура (инфраструктура или системная архитектура). Определяет, какие обеспечивающие технологии (аппаратное и системное программное обеспечение, сети и коммуникации) необходимы для создания среды работы приложений, которые, в свою очередь, управляют данными и обеспечивают бизнес-функции. Эта среда должна обеспечивать работу прикладных систем на заданном уровне предоставления сервисов своим пользователям. В зависимости от конкретных потребностей организации и актуальности решения тех или иных проблем можно выделить и другие представления архитектуры, например: Архитектура интеграции. Определяет инфраструктуру для интеграции различных приложений и данных. Например, в проектах в области "электронного правительства", когда имеется большое количество государственных информационных систем различных ведомств, возникает настоятельная потребность создания самостоятельной инфраструктуры интеграции (архитектура интеграции), с целью предоставления государством интегрированных услуг гражданам и бизнесу по принципу "одного окна". Архитектура общих сервисов. Примерами их являются такие сервисы, как электронная почта, каталоги, общие механизмы безопасности (идентификации, аутентификации, авторизации). То есть, это достаточно большое количество прикладных систем, которые носят "горизонтальный характер". Сетевая архитектура. Определяет описания, правила, стандарты, которые связаны с сетевыми и коммуникационными технологиями, используемыми в организации. Архитектура безопасности и т.д. В частности, архитектуры интеграции и общих сервисов особенно актуальны для распределенной среды органов государственного управления, поэтому эти домены там, как правило, выделяются особо. Сетевая архитектура сама по себе представляет достаточно обширную предметную область, в которой выделяется домен, связанный с сетевыми технологиями (доступ, пересылка данных, маршрутизация, коммутация и т.д.) и домен, связанный с коммуникациями (передача голоса и видео, удаленный доступ, мобильные вычисления и т.д.). Но большинство методик рассматривает эти предметные области как часть более обширных доменов, таких как архитектура приложений и технологическая архитектура, выделяя их в отдельные домены более низкого уровня на последующих этапах детального описания архитектуры предприятия.  Рис. 3. Области, входящие в понятие Архитектуры предприятия Как отдельную область, очень часто выделяют архитектуру процессов управления информационными технологиями (архитектуру операций), т.е. архитектура предприятия является неполной без архитектуры управления и эксплуатации информационных технологий, т.е. структур управления и наборов процессов, которые поддерживают и обеспечивают как инфраструктуру и прикладные системы, так и непосредственно архитектурный процесс. Принципы, модели и стандарты в рамках архитектуры предприятияОсновные составные элементы стратегии и архитектуры информационных технологий предприятия можно отобразить условно в виде следующей пирамиды, представленной на рисунке 4.  Рис. 4. Модель, используемая для описания стратегии и архитектуры информационных технологий Из данного рисунка видно, что руководящие принципы, так же, как и стандарты политики, руководства, процедуры, могут относиться абсолютно ко всем элементам архитектуры: и к данным, и к прикладным системам, и к технологической инфраструктуре. Важно отметить, что для описания "верхней" части этой пирамиды используются, в основном, такие механизмы, как декларируемые принципы. "Средняя" часть пирамиды, т.е. непосредственно архитектура, описывается в форме набора соответствующих моделей. А нижняя часть пирамиды связана с выработкой соответствующих правил, процедур или выбором стандартов. Ключевыми элементами, с точки зрения архитектуры, являются принципы, стандарты и модели. Стандарты разрабатываются на основе принципов и описывают, как принципы будут реализованы на практике. Модели являются графическим представлением принципов и стандартов и используются для описания архитектуры. При этом модели обеспечивают упрощенное представление о сложном реальном мире и создают абстрактные конструкции, в которых опущены несущественные детали и внимание сосредоточено на наиболее важных аспектах описываемого предмета. Кроме того, модели обеспечивают основу для обсуждения между различными заинтересованными сторонами одного и того же предмета. Этому посвящен следующий раздел. В общем случае практика описания стратегии и архитектуры информационных технологий, а также другие нормативные документы, описывающие принципы создания и эксплуатации информационных систем предприятия или органов государственного управления уровня региона или города, может включать в себя следующие элементы: Миссия и видение. Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий. Цели, задачи и стратегии. Архитектура информационных технологий. Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов. ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции. Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе. Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами. Реализация целей, задач и стратегий достигается через соответствующие ИТ-проекты, которые формулируются в планах на очередной период деятельности. Конечно, этот список представляется достаточно объемным, однако мы даем читателю представление об "идеальной" картине, связанной с описанием стратегии и архитектуры информационных технологий на уровне достаточно крупного организационного образования. На практике, конечно, такая полноценная совокупность документов и описаний создается в течение определенного периода времени практической работы. При этом можно рекомендовать использование следующей иерархии отношений между политиками, стандартами и процедурами. Стандарты всегда должны быть связаны с некоторыми сформулированными политиками, хотя сами политики могут и не иметь определенных стандартов "под собой". Точно так же процедуры всегда должны быть связаны с определенными стандартами, хотя сами стандарты могут существовать без связанных с ними каких-либо процедур.  Рис. 5. Политики, стандарты и процедуры Важным представляется следующее замечание, сформулированное в архитектурной методике META Group, которое касается роли принципов и моделей в описании архитектуры. Можно сказать, что существуют два различных подхода к процессам разработки, описания и использования архитектуры предприятия: существенная, возможно, даже большая часть специалистов и компаний считает, что основой архитектуры являются принципы, а другая часть придерживается точки зрения, что основой архитектуры является процесс создания моделей. META Group полагает, что при описании сегодняшней, существующей архитектуры (архитектуры "как есть") необходимо в большей степени руководствоваться декларациями принципов, на основе которой она построена; в то же время, будущие состояния архитектуры должны описываться с использованием соответствующих моделей, описывающих отдельные представления (домены) будущей архитектуры. Основой таких рекомендаций META Group являются следующие соображения. Когда организация находится в самом начале процесса разработки своей архитектуры, то, как правило, нет полной ясности и согласия по поводу используемых моделей и даже разбиения архитектуры на представления (домены). В этих условиях первое, что архитектура предприятия должна дать сразу и всем участникам процесса – это общие рекомендации по текущим проектам, чтобы их руководители могли понимать общее направление. Первым правилом является правило "не навреди", что и означает задание общего для всех стратегического направления. Это достигается через формулировку принципов, которые для этого являются очень мощным инструментом. Принципы – это высокоуровневые руководства к действию. Примером принципа может быть следующий: "Мы будем использовать передовые технологии, но только не самые новейшие и непроверенные". Конечно, это требует последующего уточнения понятий "передовые технологии" и "новейшие технологии". Принципы одновременно обеспечивают инструмент принятия неизбежных компромиссных решений при разработке моделей и обеспечения единства между различными доменами архитектуры. Эволюция содержания архитектуры предприятия по мере ее разработки и развития условно показана на рисунке 6.  Рис. 6. Эволюция контента Архитектуры предприятия Нам это замечание и этот подход кажутся очень важными и адекватными, особенно для крупных предприятий и органов государственной власти, где проект разработки архитектуры реализуется, как правило, в исключительно распределенной организационной среде. Тематика и список конкретных принципов определяется уровнем развития информационных систем предприятия, существующими приоритетами, и спектр этой тематики очень широкий. На первый взгляд, некоторые из декларируемых принципов, особенно в отрыве от остального контекста, могут звучать тривиально, как нечто само собой разумеющееся. Но их более глубокий анализ – причины, по которым эти принципы приняты, влияние на архитектуру информационных систем, – как правило, показывает важность явной формулировки таких высокоуровневых утверждений. Приведем примеры некоторых явно сформулированных принципов, которые могут относиться как к коммерческому предприятию, так и, например, к уровню регионального (городского) правительства. Оценка зрелости архитектурыКак и для всякого проекта, при разработке и внедрении архитектуры предприятия нужно уметь оценивать уровень полученного результата. Для этого META Group рекомендовала использовать шкалу зрелости, аналогичную той, которая применяется в методике Capability Maturity Model (CMM), предложенной Институтом системного инжиниринга (SEI) при Университете Карнеги-Меллона CMM. Аналогичный подход был предложен для оценки архитектур ИС федеральных органов в США. Мы неоднократно будем сталкиваться с аналогичными моделями оценки зрелости тех или иных процессов, например, процесса организации инвестиций в ИТ. В основе всех таких моделей, по большому счету, лежит новаторская работа Филиппа Кросби (Philip Crosby) "Quality is Free" (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством TQM (Total Quality Management), созданной В. Деммингом, Дж. Мураном и Ф. Кросби. Кросби разработал методику, которая включает в себя пять стадий или уровней развития процессов, связанных с качеством. Он назвал эти стадии следующим образом: неопределенность; пробуждение; осведомленность или обучение; мудрость; определенность. В отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней: Уровень_1'>Уровень 1. Начальный. Уровень 2. Повторяемый. Уровень 3. Определенный или регламентируемый. Уровень 4. Управляемый. Уровень 5. Оптимизирующий. В табл. 12.1 приведены общие характеристики уровней организационной зрелости.
Таблица 12.2 подробнее расшифровывает критерии, которым архитектура должна удовлетворять на различных уровнях своего развития.
Аналогичная модель, правда, с разбиением уровня 1 на два – "начальный" и "отсутствующий", предложена Институтом разработок архитектуры предприятия (Institute for Enterprise Architecture Developments). Интересное распределение организаций из группы Global 2000 по степени зрелости архитектуры приведено, по данным, в таблице 12.3.
СсылкиА.А. Мкртумян, А.С. Агапов, Н.Э. Михайловский, С.В. Зенин Оценка и аттестация процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504-CMM) М.: Книга и бизнес, 2001 – 348 c\ Липаев В.В. и др Применение международных стандартов в процессе разработки программных средств информационных систем Российско-американское судебное партнерство, М. 2000 Фонд поддержки системного проектирования, стандартизации и управления проектами Е.Б. Зиндер 3D-предприятие – схема архитектуры трансформирующейся системы Директору информационной службы № 4, 200 125. META Group. Turing Tao: The Enterprise Technology Model 2003 Л. Григорьев Информационные технологии: проблемы развития отрасли в России | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||