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

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

• Общей структуры элементов, компонентов, подсистем и прочих составляющих, ИС;

• Места ИС внутри конструкции метасистем, в которые она входит;

• Организации инфраструктуры, в которой происходят активности, связанные с функционированием ИС;

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

• Прочее.

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

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

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

1. Область технологических систем;

2. Пространство живых организмов;

3. Область веществ, субстанций, химических соединений;

4. Сферу социальных институтов;

Как познать и описать любую из перечисленных областей?

Ранее в курсе «Проектирование ИС», мы подробно рассматривали основные свойства системы (с точки зрения системотехники и кибернетики) Теория систем часть 1 и Теория систем часть 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для начала давайте разберем определения.

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

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

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы.

Архитектура включает:

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

2. соединение выбранных элементов структуры и их поведения во всё более крупные системы;

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

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

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

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

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

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

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

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

Чем продиктована необходимость применять единые Архитектурные подходы?

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

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

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

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

Первое измерение которое мы рассмотрим будет разложение элементов архитектуры по ракурсам представлений.

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

1. Бизнес-ракурс

2. Ракурс информации

3. Ракурс приложений

4. Технологический ракурс

1) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) - целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.

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

2) Информационная архитектура (Enterprise Information Architecture, EIA), управляемый набор методик, описывающий информационную модель предприятия, направленный на систематизацию информации помогающий заинтересованным лицам находить и работать с нужными данными, включающий:

• базы данных и хранилища данных;

• информационные потоки (как внутри организации, так и связи с внешним миром).

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

3) Архитектура прикладных решений (Enterprise Solution Architecture, ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. Делится на два направления:

• область разработки прикладных систем;

• портфель прикладных систем.

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

4) Техническая архитектура (EnterpriseTechnicalArchitecture, ETA) — комплекс программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Описывает полное представление инфраструктуры предприятия, включая:

• информацию об инфраструктуре предприятия;

• системное программное обеспечение (СУБД, системы интеграции);

• стандарты на программно-аппаратные средства;

• средства обеспечения безопасности (программно-аппаратные);

• системы управления инфраструктурой.

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

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

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

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

1. Контекст

2. Концептуальное представление

3. Логическое представление

4. Физическое представление

Первый Уровень - Контекста описывает все что окружает систему снаружи, движущие силы и факторы, оказывающие воздействие на функционирование организации. А также миссию и стратегию развития и то, как они влияют на деятельность организации и на ее приоритеты.

Другими словами, обсуждается Экосистема, в которой функционирует предприятие.

Для уровня Контекста свойственны, например, такие вопросы:

•  Каких целей хочет добиться организация?

• Почему организация занимается именно этим бизнесом: видение, миссия и цели?

•  Каковы тенденции в индустрии, в которой работает организация?

•  Как организация расположена и где она работает географически?

•  Каковы на самом высоком уровне классы информации, которыми оперирует организация?

•  Каковы базовые функции этого бизнеса?

•  В каких областях сосредоточена ключевая компетенция организации?

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

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

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

Большая часть работ этого уровня выполняется на этапе предпроектного исследования. Об этапах производства информационных систем подробнее можно узнать из моего курса «Организация процессов производства ИС».

Пример Вопросов Концептуального представления:

•  Какие области бизнеса должны быть поддержаны информационными технологиями?

•  Какая общая бизнес-архитектура (например, "фронт-офис", "мид-офис", "бэк-офис") будет использоваться?

•  Как выглядят бизнес-процессы, которые обеспечивают создание продуктов и оказание услуг?

•  Какая информация требуется для каждого бизнес-процесса и как эта информация может повторно использоваться?

•  Организован ли бизнес организации в централизованном или децентрализованном виде?

•  Какой уровень делегирования полномочий должны обеспечивать системы?

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

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

Большая часть работ этого уровня выполняется на этапе проектирования целевой системы.

Уровень Логического представления отвечает на такие вопросы:

• Какие приложения необходимы для поддержки бизнес-процессов?

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

•  Как выглядят нормализованные модели данных для этих приложений?

•  Какие прикладные системы нужны для управления данными: создания, чтения, внесения изменений и удаления данных?

•  Какие нужны технологии для реализации этих прикладных систем?

•  Как будет выглядеть распределенная архитектура прикладных систем?

• Какие стандарты должны быть приняты организацией?

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

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

Для уровня Физического представления характерны, например, такие вопросы:

• Каковы функциональные спецификации каждой прикладной системы?

• Будет ли организация разрабатывать специализированные приложения или покупать стандартные?

• Каковы критерии выбора и как будут оцениваться различные инициативы по реализации систем?

• Как данные будут представлены на физическом уровне?

В результате применения одновременно обоих описанных выше измерений мы можем получить объемное (пока двухуровневое) представление ИТ Архитектуры.

Следующее возможное деление – рамочные модели Архитектуры:

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

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

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

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

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

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

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

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

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

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

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

Отсюда вытекает следующий постулат. Существует два понятия:

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

Для пущего понимания этого явления возвратимся ненадолго к рассмотрению свойств системы.

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

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

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

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

Рассмотренная нами выше тема деления архитектуры на слои порождает следующий постулат- утверждение:

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

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

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

Подводя краткий итог вышесказанному можно констатировать:

• Архитектура определяет основные компоненты (бизнес-сервисы предприятия, прикладные системы и их модули, потоки информации и т.д.);

• Архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;

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

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

• Каждая система имеет архитектуру – даже система, которая состоит из одной компоненты;

• Архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;

• Определения архитектуры не содержат описания самих компонент.

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