ЗСМм-2-20 Шамсеева А.Р. архитектура. Общая схема архитектурного процесса
 Скачать 1.46 Mb.
|
СодержаниеВведение……………………………………………………………...……………31.Ключевые элементы архитектуры предприятия…………………………..….42. Модель процесса разработки и использования архитектуры …….………...8Заключение……………………………………………………………………….19 Список литературы………………………………………………………………20ВведениеВ последнее время внешняя среда изменяется весьма быстро, поэтому требования к адаптивности предприятий возрастают год от года. Различные аналитические исследования показали, что большинство международных компаний не успевают адаптироваться к происходящим изменениям, при этом тренд в этой области является отрицательным. Основная проблема в обеспечении адаптивности предприятий – это согласование и контроль изменений, которые необходимо провести в его рамках. При изменении целей меняется стратегия, что в свою очередь приводит к изменению бизнес-процессов и приоритетов проектов, а также организационной структуры. Все это косвенным образом влияет на уровень знаний и полномочий на предприятии и, как следствие, на информационные потоки, что в свою очередь потребует изменений в существующих информационных системах. 1. Ключевые элементы архитектуры предприятияУправление архитектурой предприятия (Enterprise Architecture) создает основу для синхронизации объектов внутри предприятия и в то же время обеспечивает их непрерывное изменение для целей оптимизации бизнеса. Контроль изменений и согласованность всех элементов архитектуры способствуют повышению адаптивности предприятия, что в настоящее время является важным фактором в конкурентной борьбе. При этом фактором, сдерживающим изменения, часто могут стать информационные системы, а значит, особое внимание следует уделять синхронизации элементов бизнес-архитектуры и ИТ-архитектуры. Для управления архитектурой предприятия используется стандартный цикл, состоящий из следующих шагов: описание существующей архитектуры, проектирование ее целевого состояния, формирование плана перехода от существующей к целевой архитектуре. На первом шаге необходимо определить, какие элементы архитектуры и в каком объеме нужно описывать. архитектура стратегия приложение рынок С одной стороны, детальность создаваемого описания означает более глубокую проработку, а с другой – появляются излишние трудозатраты, как на создание самого описания, так и на поддержку его в актуальном состоянии. Как говорится, «лучшее враг хорошего», и поэтому слишком подробное описание элементов архитектуры не приносит пользы. На этом этапе важно установить ключевые элементы архитектуры предприятия из всех возможных и сосредоточиться именно на их описании и анализе. Практика показывает, что первое рассогласование в архитектуре предприятия, как правило, возникает между целями, бизнес-процессами и организационной структурой. Во многих случаях множество целей не поддержаны необходимыми ресурсами и бизнес-процессами. Следовательно, уже в процессе анализа архитектуры можно определить план работ по оптимизации деятельности предприятия в этой области. Если проанализировать информационные технологии предприятия, то они также часто бывают несогласованными с его существующими, а тем более целевыми бизнес-процессами. Здесь тоже появляется обширное поле для оптимизации деятельности. Помимо несогласованности между ключевыми элементами архитектуры предприятия часто возникают проблемы и внутри отдельного элемента, в первую очередь это дублирование, а также организационные и информационные разрывы и т.д. Однако не только числом изменений и требованием к адаптивности предприятия вызвано такое серьезное внимание к вопросам управления архитектурой. Сложность технологических систем возрастает, что означает снижение их надежности. В этом случае формализация архитектуры становится базой для обеспечения процедур управления операционными рисками и на предприятии, поскольку если ее основные элементы формализованы, то определить риски и проанализировать эффективность процедур контроля уже не представляет особой сложности. Следовательно, наиболее критично управление архитектурой в крупных компаниях, использующих сложные технологии, которые сопряжены с множеством операционных и технологических рисков. Несмотря на разнообразие методологий в области управления архитектурой на практике большинство предприятий ограничиваются ее следующими элементами: цели бизнеса; организационная структура; ключевые показатели результативности; бизнес-процессы; портфель проектов; документы; информационные системы; знания персонала. Это тот необходимый минимум, который позволяет согласовать основные элементы архитектуры между собой. Однако если цели, показатели, организационная структура и бизнес-процессы часто уже как-то взаимосвязаны между собой, то между процессами и информационными системами такой взаимосвязи часто нет. В связи с этим одной из первоочередных задач для многих предприятий является переход от моделей и регламентов бизнес-архитектуры к определению требований к информационным технологиям и построению соответствующей им ИТ-архитектуры. Информационный разрыв вызван передачей информации от бизнес-аналитиков к ИТ-специалистам, и в этот момент формализация таких элементов архитектуры, как требования, ИТ-функции, транзакции, структура данных вместе с бизнес-процессами позволяет этот разрыв сократить. На данном этапе важно правильно использовать рекомендации, содержащиеся в методологиях описания архитектуры предприятия, например в TOGAF. Таким образом, для устранения «информационного разрыва» необходимо расширять описание существующей архитектуры предприятия и, в частности, архитектуру бизнеса в направлении ИТ-архитектуры с учетом единства используемой методологии описания как для бизнес-аналитиков, так и для ИТ-специалистов. При таком переходе от описания архитектуры бизнес-процессов к описанию ИТ-архитектуры важно формализовать несколько дополнительных элементов архитектуры. В первую очередь нужно описать архитектуру данных, которая строится на основании той информации и документов, которые используются в бизнес-процессах, после чего следует сформировать архитектуру приложений и ИТ- инфраструктуру. Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации, собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи следует использовать стандартную методологию описания данных – модель «сущность–связь» (Entity-Relationship Model – ERM), в рамках которой можно четко структурировать всю информацию. Следующий этап формализации ИТ-архитектуры – переход от архитектуры бизнес-процессов и архитектуры данных к созданию архитектуры приложений. На этом этапе важно определить классы информационных систем, необходимых для автоматизации, а также модули для каждой информационной системы. Основой для проектирования архитектуры приложений и ее синхронизации с бизнес-архитектурой является карта процессов (обобщенное представление всех бизнес-процессов предприятия). На модели архитектуры приложений располагаются основные типы информационных систем, которые далее детализируются на модели модулей информационных систем и далее до уровня отдельных экранных форм – транзакций. Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнес-архитектуры и ИТ-архитектуры являются требования к информационной системе. Фактически модели требований – это целевой функционал ИТ-решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 г. TeleManagement Forum и содержит следующие модели: модель операций телекоммуникационной компании eTOM (Enhanced Telecom Operations Map – eTOM); информационная модель телекоммуникационного предприятия (Enterprise-wide Information Framework Shared Information and Data Model – SID); структура приложений телекоммуникационной компании (Applications Framework – Telecom Applications Map – TAM). 2. Модель процесса разработки и использования архитектуры Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является систематическое и рекурсивное применение таких принципов, как: - декомпозиция на различные представления архитектуры (предметные области): область прикладных систем, технологическая архитектура и т.д.; - различные уровни детализации и абстракции для описания каждой из этих областей. Схема процесса разработки в самом общем виде представлена на рис. 1. Обратим внимание на то, что фактически здесь идет речь о параллельных активностях по определению как целевой архитектуры, так и стратегии ее достижения.  Рис. 1. Схема процесса разработки архитектуры и стратегии ИТ Эта схема состоит из следующих шагов: Общим фоном для этого процесса является мониторинг существующих тенденций в области деятельности организации и тенденций в области развития информационных технологий. Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования бизнеса и технологии на текущем этапе и на перспективу, которые задают требования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса. На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ. Принимаются общие для организации стандарты и понятия о том, что такое Архитектура предприятия: принципы, общие методы описания архитектуры и ее разделы, стандарты, конкретные продукты и технологии. Параллельно с этими процессами выполняется анализ на "системном уровне": аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внедрения технологий и приложений. Результаты вышеперечисленных этапов являются основой для выполнения "Gap-анализа", т.е. выявления расхождений и различий между существующей ИТ-инфраструктурой и желаемой архитектурой предприятия. Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информационных технологий (перечень критических процессов, подлежащих автоматизации в первую очередь и т. д.), обсуждается план детального анализа. После этого начинается фаза реализации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия. С практической точки зрения, реализация инициативы в области разработки архитектуры предприятия разделяется на несколько фаз или этапов. На каждом этапе готовится совершенно определенный набор документов и иных материалов, которые создают основу архитектуры и которые позволяют предъявлять видимые результаты деятельности рабочей группы, ответственной за всю инициативу разработки архитектуры в целом. Основой работы на этих этапах является эволюционный, итеративный процесс, связанный с определением и описанием текущего и желаемого состояния архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития (Gap-анализ), который обеспечит синхронизацию архитектуры с изменениями в функциях подразделений, с изменениями в бизнес-требованиях и изменениями в технологиях. Этот процесс условно показан на рис.2.  Рис. 2. Общая схема процесса разработки архитектуры Таким образом, мы можем сказать, что архитектура является одновременно как постоянным организационным процессом, так и результатом, который материализуется в форме моделей и документов, описывающих существующее и будущее состояние архитектуры. Разработка архитектуры является сложным процессом, который обеспечивает движение от описания общего положения с имеющимися информационными системами и инфраструктурой к практической реализации информационных систем, их эксплуатации и оценке результатов. Процесс носит нелинейный, циклический характер, и было бы ошибкой считать, что разработка архитектуры – это одноразовая кампания, которая обеспечивает простое перемещение информационных систем предприятия из состояния "А" в состояние "Б". Архитектура – это постоянный процесс, который нацелен на обеспечение постоянных улучшений в той области, которая связана с отдачей от использования информационных технологий для реализации бизнес-функций предприятия и его соответствующих подразделений. Процесс разработки и обновления архитектуры должен идти параллельно и одновременно с практической реализацией информационных систем предприятия. Это два взаимосвязанных процесса, которые, однако, имеют различные "скорости протекания". Архитектурный процесс по своей природе является концептуальным, имеет длительный временной горизонт, в то время как реализация систем ориентирована на внедрение конкретных решений и реализацию проектов с существенно более коротким временным горизонтом. Архитектура задает цели для отдельных проектов и инициатив, но важна и обратная связь: систематический анализ опыта реализации отдельных проектов и систем является неотъемлемой частью всего процесса планирования и разработки архитектуры. Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям META Group. Характерными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, даже в случае выбора какой-то другой методики, вам скорее всего придется создавать аналоги этих документов. Каждая итерация включает: Этап 1: Описание или уточнение Общего видения (видение общих требований к архитектуре). Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура и пр. Этап 3: Разработка или уточнение Плана реализации. При первой итерации этого процесса разрабатываются только те представления (view) архитектуры (предметные области, или домены, архитектуры), которые идентифицированы как наиболее приоритетные (2-3 области). Например, если будет принято решение, что наиболее острой проблемой является инвентаризация существующих на предприятии прикладных систем и составление плана изменения их портфеля (вывод из эксплуатации ряда прикладных систем, обновление или разработка новых), то такая область, как Архитектура прикладных систем, должна разрабатываться в приоритетном порядке. После завершения всех трех этапов первой итерации рабочая группа, отвечающая за разработку архитектуры, продолжает разработку архитектур остальных доменов (предметных областей), не проработанных ранее, с учетом накопленного опыта и информации на предыдущих итерациях. Этап 1: Разработка Общего видения архитектуры Общее видение обеспечивает единое понимание проблемы между функциональным (бизнес-) руководством и людьми, отвечающими за информационно-коммуникационные технологии. Оно задает контекст для всей последующей разработки элементов архитектуры. Основными элементами Общего видения являются: - описание технологических тенденций, важных для предприятия; - идентификация бизнес-требований и стратегий; - идентификация основных требований к информации и технологиям, которые важны с точки зрения реализации бизнес-стратегий; - идентификация требований к архитектуре предприятия в целом. Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей На этом этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей. Концептуальная архитектура обеспечивает общий анализ всех доменов архитектуры с точки зрения идентифицированных на этапе разработки общего видения принципов и факторов влияния. Целью Концептуальной архитектуры является перевод требований, сформулированных в Общем видении, в набор конкретных принципов, которые будут использоваться на этапе разработки архитектуры отдельных предметных областей. Этап 3: Разработка Плана реализации тап 3 включает в себя следующие два шага: Стратегия миграции и планирование реализации. Целью данного шага является определение альтернатив, взаимозависимостей и усилий, необходимых для того, чтобы обеспечить выполнение технологических требований, идентифицированных на предыдущих этапах. Результатом этого шага станет набор проектов, рекомендуемых к реализации с точки зрения достижения желаемого состояния Архитектуры предприятия и Архитектуры отдельных предметных областей. Расстановка приоритетов в плане разработки и уточнения архитектур отдельных предметных областей. На этом шаге определяются стратегические потребности и необходимые усилия для проработки архитектур отдельных предметных областей, которые либо требуют уточнения, либо не были разработаны на предыдущих итерациях архитектурного процесса. В крупной организации или, например, в региональном или городском масштабе государственного управления работа по разработке архитектуры должна выполняться на нескольких уровнях. На уровне предприятия или регионального (городского) правительства должны приниматься общие решения, обеспечивающие совместимость и взаимодействие информационных систем, а также вырабатываться другие общие требования и стандарты. На уровне отдельных крупных бизнес-подразделений или департаментов должны разрабатываться архитектуры информационных систем соответствующих структурных подразделений, оптимизированные с учетом их функций, но в рамках общих принципов, определенных в масштабе предприятия (региона, города) в целом. Одним из результатов совместных усилий по разработке архитектур различных уровней должен быть список информационных подсистем и сервисов, которые носят общий, "горизонтальный" характер, таких как управление общими для предприятия информационными ресурсами и системами, общие системы идентификации и авторизации, общие системы контроля доступа к информационным ресурсам и т.д. При организации архитектурного процесса может оказаться полезным использование упоминавшегося ранее стандарта IEEE 1471. Этот стандарт определяет рамочную модель, ориентированную на разработку комплексов с гарантированной надежностью, требуемой, например, в военных, космических и авиационных системах. Такая модель включает в рассмотрение понятия "участника" (stakeholder) и его представлений о целевой системе. На первый взгляд это может показаться тривиальным – ведь создание любой системы, в том числе и с использованием классических подходов, начинается со сбора, описания и анализа требований. Принципиальным в данном случае является признание того факта, что в подавляющем числе случаев на практике совокупность требований является, с одной стороны, неполной, а с другой – противоречивой.Направления разработки архитектуры: "сверху-вниз" или "снизу-вверх". В общем виде можно сказать, что существуют два принципиально различных подхода в разработке архитектуры предприятия. Подход "сверху-вниз" предполагает достаточно широкий охват проблем и точное следование формальному процессу. Основу этому подходу положили методики Захмана и Спивака. Он начинается со сбора информации, требующейся для описания различных доменов архитектуры "как есть". Далее следует этап, связанный с описанием и реинжинирингом бизнес-процессов, консолидации прикладных систем, выстраивание архитектуры данных и, наконец, стандартизация технологической архитектуры. Например, многие государственные проекты ориентированы на этот подход (например, в США в рамках Федеральной архитектуры FEAF). Подход "снизу-вверх", когда процесс начинается со стандартизации инфраструктурных технологий (технологическая архитектура), а затем развивается в направлении решения проблем более высокого уровня и, в конечном итоге, решает вопросы, связанные с бизнес-архитектурой. Этот подход, видимо, имеет более широкое распространение в бизнесе и в частном секторе. В зависимости от ряда факторов, предпочтение отдается тому или иному подходу. Например, когда проект разработки архитектуры должен быстро показать отдачу, включая финансовую, или если разнообразие используемых в организации технологий явно приводит к падению качества ИТ-сервисов, то предпочтительным является подход "снизу-вверх". Организации, которым нужно решить с помощью архитектуры существенные проблемы, связанные с неэффективностью или большим количеством излишних бизнес-процессов или с наличием перегруженного набора прикладных систем, и которые готовы ждать как минимум год получения видимых результатов от разработки архитектуры, должны использовать подход "сверху-вниз". Наилучшим вариантом, однако, может стать гибридный подход. В любом случае, выбранная стратегия должна отвечать конкретным потребностям организации, и в любом случае, требуется поддержка со стороны высшего руководства и понимание того, что создание архитектуры – это долговременный процесс изменений. Аналогичным образом процесс планирования архитектуры информационных систем предприятия, а также реализация этой архитектуры являются во многом политическим процессом: всегда есть различные мнения по поводу приоритета проектов или необходимости использования тех или иных технологий. И надо заметить, что процесс управления и контроля развития информационных технологий предприятия (то, что по-английски называется governance) остается менее развитой и зрелой дисциплиной, чем планирование города. Кроме того, прикладные системы, используемые в типичной организации, как правило, стали результатом работы различных групп разработчиков, приобретались у различных поставщиков и в разное время. Очень часто при создании этих систем разработчики не имели практически никакого представления об архитектуре других систем предприятия. Системы неизбежно различаются по своей внутренней архитектуре, форматам используемых данных; и, тем не менее, многие эти системы должны в какой-то степени работать совместно. Такая ситуация аналогична проблемам городского планирования или организации работ, связанных с городской инфраструктурой. Общегородской план устанавливает некоторые общие правила на расположение, устройство и внешний вид микрорайонов и зданий: стандарты (размеры труб, напряжение в электросети, ширина дорог), сертификация (участие в строительстве только специально авторизованных компаний или использование сертифицированных материалов), управление (правила получения разрешений и пр.). Кроме того, городской план включает принципы использования общих ресурсов и сервисов, к которым отдельные здания могут быть подключены: водоснабжение и электричество, канализация и сбор мусора, телефоны, Интернет и кабельное телевидение. Точно также при реализации информационных систем предприятия требуются как меры регулирования архитектуры отдельных систем (используемые технологии, протоколы, стандарты и т.д.), так и правила создания и использования общих сервисов, таких как электронная почта. Планирование и обеспечение жизнедеятельности города требует четкого разделения труда: уровень города в целом, уровень отдельных городских зон и местные эксплуатирующие организации. Аналогично задача проектирования архитектуры предприятия в целом отличается от проектирования архитектуры отдельных систем, и отдельный вопрос – это эксплуатация систем. Какие уроки можно извлечь из этой аналогии архитектуры информационных систем предприятия и городского планирования? Первое: необходимость в наличии на предприятии единой архитектуры ИТ. В противном случае, ваш "электронный город" будет похож на хаотичную застройку Бангкока, где супер-небоскребы соседствуют буквально с курятниками. Второе: помните о том, что разнообразие систем и платформ – это неизбежность для предприятия, так что интеграции нельзя достичь выбором единой платформы и технологии. У вас будет много "зданий" разных цветов и архитектуры. Думайте об архитектуре интеграции, которая основана не на единстве платформ, а на принципах сервис-ориентированной архитектуры. Третье: при разработке архитектуры предприятия необходимо сбалансированно сочетать централизованные и децентрализованные методы планирования и управления. Неразумно и невозможно контролировать расположение комнат в каждой квартире или стоимость кусочка мыла в магазинчике за углом. Вы должны использовать принципы ограниченной автономии, характерные для управления городом, и дать возможность владельцам бизнес-процессов оптимизировать свои информационные системы при наличии разумного количества общих для предприятия ограничений. Четвертое: важность стабильной инфраструктуры. Инфраструктура ИТ должна обслуживать текущие потребности и в какой-то степени предвосхищать будущие потребности в системах. Пятое: планирование "различных зон ИТ", так же как планирование различных городских зон. Мы уже говорили, что различные типы бизнес-процессов и приложений (транзакционные, аналитические и т.д.), требуют различных технологий. Поэтому один из возможных путей развития ИТ на предприятии – это идентификация таких "зон" и возможность их относительно независимого развития. Шестой вывод заключается в максимальном использовании того, что есть. Любой город старается по максимуму использовать ресурсы существующей инфраструктуры, прежде чем запускать новые дорогостоящие проекты ее обновления. Точно также большое количество имеющихся на предприятии унаследованных систем – это, скорее, актив, чем пассив, и его можно и нужно эффективно использовать. Функционал этих систем можно, в частности, "открыть" для интеграции с новыми прикладными системами, используя адаптеры и технологии web-сервисов. ЗАКЛЮЧЕНИЕАрхитектура предприятия - это наиболее общее и всестороннее представление предприятия, как хозяйствующего субъекта, имеющего краткосрочные и долгосрочные цели ведения своей основной деятельности, определенные миссией на региональном и мировом рынке, и стратегией развития, внешние и внутренние ресурсы, необходимые для выполнения миссии и достижения поставленных целей, а также сложившиеся правила ведения основной деятельности -бизнеса. Список литературыВасильев Р. Б., Калянов Г. Н., Левочкин Г. А., Лукинова О. В. Стратегическое управление информационными системами; Интернет-университет информационных технологий, Бином. Лаборатория знаний - Москва, 2013. - 512 c. Гриценко Ю. Б. Архитектура предприятия : Учебное пособие / Гриценко Ю. Б. – 2011. 256 с. Данилин А.В., СлюсаренкоА.И., Учебный курс – Архитектура предприятия [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/itmngt/entarc/ Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. Учебное пособие: М.: Финансы и статистика, 2006. |
