Содержание курса

• Понятие «Архитектура»

• Бизнес-архитектура

• Информационная архитектура

• Архитектура прикладных решений

• Технологическая Архитектура

• Подходы к построению Архитектуры

• Графический язык моделирования ArchiMate

• Архитекторы

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

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

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

ИТ-архитектура предприятия (Enterprise IT Architecture) — это системное представление структуры, компонентов и взаимодействий всех информационных технологий, которые поддерживают бизнес-процессы, ценности и стратегию организации. Иными словами — это “скелет” технологической среды, который обеспечивает реализацию бизнес-архитектуры и поддержку бизнес-способностей.

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

• Стратегической. Ориентированной на выполнение сложившихся стратегий и операций; 

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

• Сдвигающей. Используемой в виде инструмента для увеличения эффективности бизнеса; 

• Поддерживающей. Когда ИС не имеют ключевой роли в функционировании предприятия. 

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

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

По существу, описание ИТ-архитектуры должно обеспечить:

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

2. Структурирование и классификацию приложений с целью поддержки формирования и функционирования информационного пространства.

3. Сочетание схем организации, размещения и навигации, технологических решений, на базе которых реализуется вся информационная система.

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

• Enterprise Information Architecture (EIA) – информационная архитектура;

• Enterprise Solution Architecture (ESA) – архитектура прикладных решений;

• Enterprise Technical Architecture (ETA) – техническая архитектура.

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

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

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

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

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

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

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

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

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

Выделяют три основных грани информационной архитектуры:

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

• Основа цифрового интеллекта предприятия. Использование информации как стратегического корпоративного ресурса и неотъемлемой части "интеллектуального капитала" организации. Управление качеством данных, (актуальность, точность, непротиворечивость и прочее), обеспечивая основы для аналитики, формирования управленческих решений и цифровой трансформации.

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

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

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

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

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

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

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

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

Если Бизнес-архитектура отвечает на вопрос: "Кто и что будет делать, с учетом нашего общего видения, целей и стратегий?", то Архитектура информации отвечает на вопрос: "Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?"

3.1. Жизненный цикл информации

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

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

1. Определение состава и структуры информации, а также организация процессов ее сбора.

2. Организация обработки и хранения собранных данных

3. Анализ и потребление (использование) данных для получения бизнес-выгоды.

Начнем рассмотрение с определения того, что же мы подразумеваем под понятием Информация?

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

3.2. Классификация информации

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

Классификация информации — это процесс распределения информации по категориям (классам) на основании общих признаков или свойств.

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

Например:

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

• Разделяемые справочники (reference data) систематизируют и классифицируют другие данные, а также связывают(интегрируют) между собой данные различных организаций;

• Оперативные (транзакционные) данные (transactional data) отражают информацию о ходе исполнения бизнес-процессов;

• Исторические данные (historical data) образованы из прошлых версий мастер-данных, справочников и транзакционных данных. Такие данные привязаны ко времени совершения операций;

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

Существует и множество других классификаций, например:

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

• По ценности (критически важная, обычная, публичная и прочее);

• По типу происхождения (сырые данные, синтетические, обогащенные и прочее);

• По жизненному циклу и прочее.

3.3. Качество информации

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

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

В свою очередь качество информации влияет на:

• эффективность бизнес-процессов (ошибки в данных → сбои в процессах);

• точность аналитики и прогнозов;

• принятие управленческих решений;

• финансовые показатели (ошибки в заказах, расчётах, поставках);

• соблюдение регуляторных норм (например, GDPR, ISO 8000).

В качестве основных измерений качества информации принято рассматривать:

1)  Доступность данных

• Насколько быстро можно получить доступ к ним;

• Насколько быстро и удобно можно искать информацию и настраивать правила ее учета;

2)  Доверие к данным

• В какой степени можно рассчитывать на их достоверности;

• Актуальность состояния данных;

3)  Релевантность. Полезность данных для использования в контексте деловой деятельности;

4)  Точность. Насколько близки к истине свойства и содержание;

5)   Полнота. Достаточность собранных данных для использования в деловых процессах;

6)   Конфиденциальность. Где и кому должны быть доступны или недоступны;

7)   Стоимость. Затраты, понесенные на получение, предоставление, использование.

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

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

3.4. Стратегии управления данными

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

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

Стандарт представлен в виде набора требований для высоконадёжных систем, прежде всего, реляционных СУБД.

Вот что означает каждое из этих требований:

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

C — Consistency Непротиворечивость (или Согласованность) — каждая транзакция переводит систему из одного согласованного (устойчивого) состояния в другое;

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

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

Например, вы решили отправить партнеру деньги.

Когда вы делаете перевод внутри банка, то:

1.  В результате первой операции: С вашего счета деньги спишутся

2.  В результате второй операции: Партнеру на счет поступит сумма, эквивалентная списанной с вашего счета.

2.а. При этом, если у вас на балансе нет нужной суммы — система прервет первую операцию и сообщит Вам об ошибке. Вторая операция даже не начнется.

2.b. Но, если у партнера заблокирован счет— деньги ему не зачислятся. Второй запрос будет отменен. Но, у вас они в результате успешного проведения первой операции уже списались!

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

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

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

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

• Устойчивость к разделению. Расщепление распределённой системы на несколько изолированных узлов не приводит к некорректности отклика от каждого узла. То есть система должна сохранять работоспособность в случаях частичной потери данных или отказов отдельных компонентов

Поэтому при проектировании архитектуры распределённых хранилищ предполагается отказ от части требований ACID для снижения строгости условий и применения подхода BASE. Который можно характеризовать такими тезисами: “В основном доступный”, “Мягкое состояние”, “Постепенно согласованный”. Подход BASE делает упор на доступность данных и их масштабируемость, позволяя достигнуть этих целей за счет уступок в отношении согласованности данных. В этом подходе допускается, что данные могут находиться в “гибком” состоянии, то есть состоянии, которое может быть не совсем точным или актуальным в любой момент времени. Однако, постепенно состояние данных становится согласованным, когда система продолжает работу и данные обновляются.

Варианты выбора стратегии:

+ Доступность + Согласованность - Устойчивость к разделению

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

+ Согласованность + Устойчивость к разделению - Доступность

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

+ Доступность + Устойчивость к разделению - Согласованность

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

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

3.5. Форматы взаимодействия при обмене данными

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

• Интегрированная система – система, в которой все входящие в нее подсистемы работают по единому алгоритму, то есть имеет единую точку управления. И

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

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

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

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

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

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

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

• надёжность обмена данными,

• скорость реакции системы,

• устойчивость к нагрузкам,

• стоимость поддержки и масштабирования

Например, доставка данных по трём независимым осям — это концепция, применяемая при проектировании распределённых информационных систем и архитектур обмена данными.

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

3.6. Модели для формализации информационной архитектуры.

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

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

• концептуальный уровень – описывает высокоуровневые модели, семантику предметной области;

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

• физический уровень – описывает реальное расположение данных внутри информационных систем и места их хранения

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

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

В результате процесса разработки моделей архитектуры информации должны быть сформированы:

• документированное описание существующих источников данных;

• модели данных;

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

• описание решений по организации хранения данных – от общих каталогов до витрин и хранилищ данных;

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

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

1. Процессы обработки информации (Information value chain);

2. Основные информационные объекты, связанные с бизнес-событиями;

3. Информационные потоки;

4. Принципы и политики управления информацией.

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

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

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

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

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

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

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

• формирование интегрированных представлений данных, таких как витрины и хранилища;

• интеграция метаданных, что позволит обеспечить целостное представление данных из различных источников;

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

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

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

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

3.7. Оценка Зрелости компании в области управления данными.

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

Оценка зрелости нужна, чтобы:

• определить текущее состояние управления данными;

• выявить пробелы и риски (например, плохое качество, отсутствие ответственных, дублирование данных);

• разработать дорожную карту развития Data Governance;

• выстроить культуру принятия решений, на основе данных (Data-Driven Culture);

• повысить эффективность и снизить затраты на работу с информацией.

Для комплексной картины анализируют несколько доменов управления данными (по стандарту DAMA DMBOK):

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

• понять, где она находится на пути к «data-driven» организации;

• определить пробелы и приоритетные области развития;

• выстроить стратегию Data Governance и архитектуры данных;

• повысить качество информации и эффективность решений.

В следующей части мы рассмотрим следующий слой – Архитектура приложений.